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.
That is a weird complaint. Letting things shut down properly is a feature. If you don’t like it you can disable it:
# /etc/systemd/system.conf DefaultTimeoutStopSec=0Never 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.
Yes, maybe, but every single time? Things shutdown without systemd and nothing seems to explode.
Just about every service manager has a similar concept. systemd makes it very visible (and maybe has a longer default timeout? I haven’t checked) but this is a generic problem.
Programs should be fine if you just send SIGKILL but it is often better if you let them shut down gracefully. For example maybe it wants to tell it’s clients that they should fail over to another host so that they won’t experience interruption, and maybe the database wants to flush it’s updates to disk so that it doesn’t need to waste time recovering from the WAL on next boot. But at the end of the day it isn’t systemd’s fault. It is just enacting the configuration. If you think that 90s is too long you can change it.
That’s good to know.
I’m just saying that for a hobby admin like me, other init systems don’t seem to have this behaviour or configuration requirement. And I find it strange that it always goes “isn’t systemds fault”… it’s clearly doing something different here than other inits by default. And that is what is criticised.
I seem to remember this problem on Arch before systemd. But maybe I am misremembering. I also fail to imagine a way to avoid this issue, but maybe other systems are doing something clever that I didn’t think of.
I’m saying this as a casual hobby admin:
Systemd saying “it’s not my fault” and “so you think you’re better than me?” pretty much sums up my user experience with it.
To me, this just isn’t very inspiring. Each to their own I guess.
Only because something is the default, it does not have to be a good idea.
deleted by creator