Sharing this blog post because I liked reading it. Nice photos and images and shows lots of options. The section about Gentoo Linux suggests it is unclear whether Gentoo uses Systemd. From what I’ve seen after tinkering with a Gentoo container last week is that Systemd is an option for “make world” but not the default.
Never understood how systemd, telling an application to stop, and then waiting on it to stop and it doesn’t, is a systemd problem. This is an application that isn’t shutting down properly or they unit done was configured incorrectly.
If I tell my car to turn off and when I turn the key of, the car keeps on rubbing, is that my fault or the car’s?
Also as for the container issues, a lot of these container platforms are built on top of systemd and leverage systemd, because it makes their jobs easier. The containers devs could decide to handle cgroups themselves, but instead they’ll push systemd to do things it wasn’t intended to do and then blame systemd.
I will say, I am biased. I work for Red Hat, primarily in systemd support and I with closely with the systemd devs. Is it perfect? Not at all. A lot of stuff is completely broken, but the devs are always willing to listen and try to make it better.
deleted by creator
“I guess in all those years with sysv,openrc,runit it simply didn’t show its shutdown slowness clearly, if it did not shutdown that fast. On FreeBSD stopping a desktop computer is always fast, never a delay and never a problem because of that. I guess it also had to do with the fact that I was playing with Ubuntu on a pi4, which comes with snap daemon and what not.”
I know nothing about runit or openrc, but I do know about sysv and upstart(which masquerades as sysv so most folks probably think they’re running sysv and really it’s upstart). sysv and upstart don’t manage the process the way that systemd does. It just runs a start script and walks away. So there’s no true tracking of if an application is misbehaving or not. 99/100 the script runs a command and puts it in the background, and then moves on so that other scripts can do their thing. If all init scripts would wait for every process to come down, then I would imagine we’d see a lot more of what systemd does, which is waiting on something to stop properly.
I feel like there’s a huge misconception about systemd, regardless of what folks think, it is NOT just an init system. upstart, sysv, are just init systems. systemd is a full management layer. As well as contrary belief, a LOT of what systemd does is all modular.
You don’t NEED systemd-logind or systemd-homed or systemd-networkd, again I work for Red Hat, we often don’t allow things in because they don’t pertain to us (looking at you systemd-homed). So the fact that your distro of choice DOES have this, means the devs made the decision that this systemd piece solves a problem for them. You do NOT need it.
Now, if you do not have systemd-logind, then yes, you’re going to be limited in what you can use. Gnome has decided to make a hard dependency on systemd-logind. Again though, is that systemd’s fault or Gnome’s?
It’s just code, if you don’t like it, don’t use it. If you have a problem with it, please report a bug so it can be fixed or so folks can understand how to use systemd or help the systemd devs understand use cases.
I will state that systemd source is a MASSIVE labyrinth and pisses me off endlessly, but it’s moving more towards like what the kernel is. But as you have kernel space and userspace, now there’s kind of a system management space.