Systemd, ten years later: a historical and technical retrospective

The article goes into detail about why there was a desire from some distro maintainers to switch to something else. (clean slate).

The reason I accused you of not reading the article is because it's very clear why systemd was adopted.

1) RH Made it, that doesn't automatically make it good, but there was a lot of posturing from the RH devs to get more things tied in to it under the guise of "all distros will use us eventually, they're already in the process of adopting us!"

2) There was a strong desire to get off of sysvinit, many alternatives had come and gone, though most had the desire to be backwards compatible, none could get any real traction, mostly because it was hacks on hacks. Upstart was promising but people didn't use it properly.

3) GNOME added a hard dependency. Small in isolation but then.

4) UDEV was made systemd-only. UDEV being something that underpins a lot of software. A fork was made (eudev) but that was only the beginning because krdb was next to be systemd only.

5) when it came time for Debian to talk about systemd as the last major upstream distribution (IE: one that sysadmins actually deploy and one that other distros are essentially variants of): it was not "systemd or alternatives" it was "how much systemd do we have to take to be able to support most software."

6) When your distro can't take a major desktop environment, that's a lot of points off of your distro.

--

People choose their distro, but their distro often chooses a distro.

If you're a business building your company, you don't trust Gentoo- you run it on RHEL, Debian or potentially Ubuntu these days.

The less systems touches the better.

>I would urge you to actually check with your system instead of blindly dismissing me as wrong just because your bash script happened to work without error.

Who said this was bash? The script from all those years ago worked perfectly without race conditions.

>They don't have the problem because they use special syscalls for this. But SysV-based systems have historically used procfs to implement ps.

Makes no difference, procfs works fine for this.

>Try unmounting proc and running ps or kill and see what happens.

You're effectively never unmounting procfs. Also, if you managed to, systemd would crash!

>If you can't do it then your system suffers from the problem, which is that you can't safely send a signal to the process after reading it because there is no guarantee that the actual PID will persist in between calls to read() and kill().

There's maybe 10 lines of code to ensure that logic. Again, middling sysadmin work.

>POSIX says nothing about this because it doesn't specify procfs, or how pkill should actually be implemented. This is all fair game as far as compatibility is concerned.

POSIX does say something about this; read about signals. You stop the process before killing it, and ensure that the start time is the same for the stopped process before the kill. That completely eliminates the race condition, using basic POSIX signals.

>There is also the other more obvious race condition in your bash script which can also be pre-empted in between the calls to ps and kill.

That race condition is eliminated with the logic above. That eliminates the PID reuse race condition, even if it's very rare.

>reuse has been a known problem for decades and Linux finally got a solution to it a couple years ago with pidfd_send_signal.

That functionality is where it belongs now, so instead of coding a logic every time you have to ensure PIDs, it's now handled for you.

>There is also the matter of cgroups but I am not going to get into that because I doubt you will want to hear about it.

Correct, I don't want to hear it from someone who doesn't understand POSIX and basic/intermediate sysadmin work.

Replacement for "no problem" should run without problems.

python2 had no problems - there was a clear transition path:

    1. "str" => b"str"
    2. wait some time
    3. "str" is u"str"

SysV, rc.d had no problems - just wait till systmed is ready.

If SysV was as bad there would be same amount of outcry as with systmed

Was it really necessary to make it painful?

Who? Somehow systemd defenders has no empathy and Lennart Poettering is a prime example. No matter right them or wrong they are perceived as threat.

Just be nice. It may hinder innovation but it helps community.