GNOME and/or systemd

GNOME and/or systemd

Posted Nov 2, 2012 21:58 UTC (Fri) by nix (subscriber, #2304)
In reply to: GNOME and/or systemd by HelloWorld
Parent article: GNOME and/or systemd

How do those scripts make sure that things like double-forking perl scripts started by apache are killed when apache is? Oh wait: they don't.

And I don't care. In my entire professional life I have never ever been bitten by this problem. Adding instability to my system to fix a theoretical problem which even if it hit would have zero negative consequences is not something I am willing to do right now.

Except when sshd(8) was shut down before and you thus don't have a shell to run kill(1) from, which is common when rebooting a machine.

Er, if that's happened your network interfaces have almost certainly been shut down as well. How on earth is systemd supposed to help here? systemd-telepathyd doesn't exist yet as far as I know. (Aside: my sshd never gets shut down until the mass-process-kill right before umount of /usr. It's a critical tool in remote system recovery: killing it explicitly earlier than absolutely necessary strikes me as a bad idea.)

Otoh, all those pig ugly shell scripts you mentioned earlier can and do fail all the time.

You don't get it. They don't fail for me. I'm perfectly willing to believe that systemd is the bees' knees and better in all sorts of ways: but it is more unstable than sysvinit PID 1, and as such on systems where stability is valued (such as every single one I work on), I'm not willing to sacrifice that stability for the sake of improvements which I really don't care very much about. (Yes, they're all nice: are they worth destabilizing my systems for? No. Others may disagree: their stability tradeoffs are different.)

You compare sysvinit to systemd and ignore all those by no means trivial shell scripts which do all the actual work

Those shell scripts are not running all the time. Those shell scripts do not have PID 1. If those shell scripts go wrong, the kernel does not panic. Is this really so hard to understand?

Otoh, you are willing to use the Linux kernel

I have no choice: nothing else will provide the features I need. (Also I'm paid to work on Linux system-level software!)

The Linux kernel introduces instability, granted, and every upgrade is a bit hair-raising (even stable kernel upgrades these days! :) ). However, systemd introduces more instability, and just like the kernel -- and unlike almost everything else other than glibc -- can instantly wedge and panic my system if it goes wrong. If I would prefer less instability to more, and am happy with the minimal features sysvinit provides (as I am), it follows that I should avoid systemd. As I do.

Heh, so you stick to tried-and-true file systems like ext4?

Yeah, that burned me a bit recently -- and I agonized for some time before deciding to use it in 2009. However, it's a hell of a lot faster than ext3 for my use case, the extents are hugely preferable for the very large disk images which I (like so many other people) spend a lot of time in these days, it has a much much faster fsck which is useful when disaster strikes, and it has an incredibly responsive and helpful upstream.

The latter factor cannot be underestimated. Lennart is also responsive, but he is all bristling with opinions I strongly disagree with, sharp edges and active but invisible laser beams: dealing with him is a lot more stressful than dealing with e.g. tytso. I do not like the thought of getting a load of social stress when already stressed out from trying to fix a system-destabilizing problem, and that's what I suspect I'd get from systemd.

This too is something that probably doesn't apply to other people: a huge proportion of my life has always been devoted to stress management, and 'X is more stressful than Y' is almost always a reason to choose Y over X, regardless of any other benefits of X. In this case, systemd bugfixing is both more likely and more likely to be stressful than the nigh-nonexistent sysvinit bugfixing: thus, sysvinit wins by default, regardless of any killer features it may or may not have. Other people have different priorities.

systemd is *way* less complex than what it replaces.

I did not say 'systemd'. I said 'PID 1': that component of systemd which if it crashes panics the kernel. systemd's PID 1 is much much more complicated than the tending-to-trivial sysvinit PID 1. It is also newer, and changing much faster because it is not years maintenance-dead: several commits a month just to systemd/src/core/main.c. Thus it is much more likely to contain bugs that cause it to die (and panic the kernel) than sysvinit. Now, yes, the shell scripts that sysvinit runs to boot the system are horrible nightmares that are better off dead -- but they only run at boot so cannot panic the kernel during normal operation.

sysvinit is dead simple and utterly stable. systemd PID 1 is terrifyingly complex by comparison. Sorry, for people who value stability, systemd is still completely out of the question, and will be for years. You'll note that this would be true no matter the code quality of systemd, no matter its benefits, it could be the best code in the history of the human race -- where things that can panic the kernel if they go wrong are concerned, that's irrelevant beside the failure risk.

---

(Log in to post comments)