Comment by foresto
1 year ago
> systemd has been a net positive for the linux ecosystem.
You're presuming to speak for an awful lot of people there, on a topic that would be difficult to measure.
> since the beginning of systemd people have moaned
> it's quite annoying that the armchair linux experts complain
Now you're overgeneralizing, and doing so in a dismissive and patronizing way.
Here are a few examples of problems I have with systemd:
System shutdown/reboot is now unreliable. Sometimes it will be just as quick as it was before systemd arrived, but other times, systemd will decide that something isn't to its liking, and block shutdown for somewhere between 30 seconds and 10 minutes, waiting for something that will never happen. The thing in question might be different from one session to the next, and from one systemd version to the next; I can spend hours or days tracking down the process/mount/service in question and finding a workaround, only to have systemd hang on something else the next day. It offers no manual skip option, so unless I happen to be working on a host with systemd's timeouts reconfigured to reduce this problem, I'm stuck with either forcing a power-off or having my time wasted.
Something about systemd's meddling with cgroups broke the lxc control commands a few years back. To work around the problem, I have to replace every such command I use with something like `systemd-run --quiet --user --scope --property=Delegate=yes <command>`. That's a PITA that I'm unlikely to ever remember (or want to type) so I effectively cannot manage containers interactively without helper scripts any more. It's also a new systemd dependency, so those helper scripts now also need checks for cgroup version and systemd presence, and a different code path depending on the result. Making matters worse, that systemd-run command occasionally fails even when I do everything "right". What was once simple and easy is now complex and unreliable.
At some point, Lennart unilaterally decided that all machines accessed over a network must have a domain name. Subsequently, every machine running a distro that had migrated to systemd-resolved was suddenly unable to resolve its hostname-only peers on the LAN, despite the DNS server handling them just fine. Finding the problem, figuring out the cause, and reconfiguring around it wasn't the end of the world, but it did waste more of my time. Repeating that experience once or twice more when systemd behavior changed again and again eventually drove me to a policy of ripping out systemd-resolved entirely on any new installation. (Which, of course, takes more time.) I think this behavior may have been rolled back by now, but sadly, I'll never get my time back.
There are more examples, but I'm tired of re-living them and don't really want to write a book. I hope these few are enough to convey my point:
Systemd has been a net negative in my experience. It has made my life markedly worse, without bringing anything I needed. Based on conversations, comments, and bug reports I've seen over the years, I get the impression that many others have had a similar experience, but don't bother speaking up about it any more, because they're tired of being dismissed, ignored, or shouted down, just as I am.
I would welcome a reliable, minimal, non-invasive, dependency-based init. Systemd is not it.
When it comes to the shutdown issue, I'd argue this is a side-effect of systemd bringing some consistency and correctness to what used to be the wild west, and is highlighting some issue that was before overlooked.
Granted, in a lot of cases the issue probably wasn't a big deal (the system is being shut down, the user is already logged out, do you really care that a system background process is being shut down cleanly?) but from systemd's perspective there's no difference between that and an actually business-critical process that should absolutely be allowed to terminate cleanly before unmounting the filesystem and powering off the machine.
> It offers no manual skip option
ctrl-alt-del skips iirc?
Systems isn't blocking the shutdown. Systems is being blocked by a service. Since you are saying that you can't track down the exact service, you must be using a container runtime like docker or LXC which is not transmitting the kill signal properly to the container to shut it down. The container itself then keeps running for whatever reason. This entirely depends on your particular setup and has very little to do with systemd.
> Since you are saying that you can't track down the exact service,
That is not what I said.