> Yep. I know sysvinit is 'broken' in the sense that I can't stop a service except by running, e.g. /etc/init.d/blah stop (those scripts may be pig ugly and better off dead, but they work,
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 if they don't, kill(1) does).
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. I actually remember a comment from somebody here on lwn who had to drive hundreds of miles to a server room precisely because of this.
> However, it works in the sense that the system boots reliably, 100% of the time: sysvinit /sbin/init has never ever once failed for me, probably because it is dead stable and simple and does almost nothing and never changes.
Otoh, all those pig ugly shell scripts you mentioned earlier can and do fail all the time. Cyberax pointed to this blog post earlier, and that's but one example. http://netsplit.com/2012/10/30/goodbye-ubuntu/
You compare sysvinit to systemd and ignore all those by no means trivial shell scripts which do all the actual work and which, unlike sysvinit itself, change all the time and are riddled of bugs. This is exactly the kind of apples-to-oranges comparison I meant earlier.
> And it uses large, complex libraries like libdbus which I *know* to have had crash and security bugs, and fairly recently at that. I'm not willing to tolerate the risk of losing PID 1 to such bugs
Otoh, you are willing to use the Linux kernel, which is much, *much*, *MUCH* bigger and more complex than libdbus, gets a major release with tons of changes every ~3 months and has security issues so regularly that its developers don't even bother documenting them anymore. Yeah, that makes sense.
> In this it is very like filesystems: I don't use btrfs anywhere I need to keep running in order to get my work done either
Heh, so you stick to tried-and-true file systems like ext4? Oh, the irony :)
> The complexity and resulting potential instability of PID 1 is the important thing.
systemd is *way* less complex than what it replaces. This guy put it best: http://lwn.net/Articles/459725/