Hacker News Reader

Comment by _emacsomancer_ | Hacker News Reader

systemd is interesting as an innovative init/daemon-manager(+), but I remain convinced it's not ideal that it is de facto Linux default init. Surely the default init should be something more manageable (i.e. with fewer attack surfaces) like runit or OpenRC (in combination with something, perhaps runit) or s6 etc.

View on HN

I think it would be great to run systemd as pid 2 with a bare-bones pid 1 that only took on the responsibility of (1) spawning a service manager as pid 2, and (2) killing reaping zombies. This is pretty much what BSD's init(8) does today[0], except with /etc/rc as pid 2 instead of systemd.

(I'm not advocating for /etc/rc — it sucks. I much prefer systemd-style dependencies, service management, etc. But bloating the code size and responsibility of pid 1 is a common systemd complaint that would be trivial to fix.)

[0]: Well, it does some other crap too that could / should probably be removed, like having a notion of run level (multiuser, single user) and spawning getty(8)s. But mostly it's a tiny barebones program that spawns pid 2 and reaps zombies.

I think it would be great if such things were options, yes. Despite the common argument that systemd is actually modular, I haven't seen a lot of modular use of its pieces. In practice, use of systemd (and, again, I'm complaining more about distro devs than systemd devs) has seem to make things more inflexible (and brittle). E.g. Gnome Shell ended up with a practical dependency on systemd, though this has been successfully worked around. Snaps ("Snaps are universal Linux packages") are really 'universal systemd packages' (and in fact only 'universal Ubuntu packages' if you want sandboxing). But hopefully at some point it will be possible to more easily use the good bits of systemd without having to go 'whole hog' (so to speak).

The claim that systemd is modular is a brilliant marketing gag that rests entirely on how you define modular: software parts that are separated by clearly delineated interfaces can be called modules without being exchangeable. So in the eyes of the systemd guys the thing is perfectly modular, but as the users noticed, no part is exchangeable, which is what the other camp wants. And both camps get hung up over the contradictions without realizing that they need to redefine their nomenclature first.

You can go start your own systemd free distribution.

For everyone else, there is a reason they centralized on it, and its not because Lennart was stalking their mailing lists threatening to send them expired cheese. Systemd is not perfect, but it is infinitely better than a sludge of shell scripts.

There already are plenty of systemd-free distributions. Not because the developers hated systemd, but because they decided using a baroque init+daemon-manager+logger+.... wasn't the best idea.

> For everyone else, there is a reason they centralized on it, and its not because Lennart was stalking their mailing lists threatening to send them expired cheese. Systemd is not perfect, but it is infinitely better than a sludge of shell scripts.

This is such a disingenuous argument. Don't like Ford? What, you want the horse-and-carriage back?

I'm not arguing for sysv init. Nothing in what I've said references sysv init, and - if my choices were (a) sysv init, and, (b) systemd, I would indeed choose (b). But that isn't the full range of choices.

There are various non-sludge-of-shell-script choices which aren't systemd. Including OpenRC, s6, runit, Shepherd. I haven't used the first two extensively, but I have the latter two, and both were better experiences than systemd: they are faster, they are more comprehensible, and they are less error-prone.

On the other hand, my systemd-running home desktop - every time I want to reboot, I end up REISUB'ing it because I don't feel like waiting 2-5 minutes for systemd to release it. I don't have that issue on any of my other, non-systemd-powered machines. They all shut down/reboot cleanly and quickly.

This attack doesn't touch the init system's attack surface though. It breaks journald, which is a separate program that you don't even have to run (syslog daemons still work)

Calling this a bug in the init system is like assigning fault for bugs in eg. rsyslog to sysvinit

This is disingenuous, systemd-journald is the default in every systemd-using distribution I am aware of. The philosophy of systemd is all about tight coupling and forcing its singular vision on end users. When that vision falls apart you can not claim it is not really a systemd problem because in theory you could have gone out of your way and done something that is not encouraged.

But you know that my post is a criticism of the systemd ecosystem, or, more specifically, its status as the de facto. All my systems that run systemd run journald; all of my systems that run journald run systemd. Because those are the choices the distro devs made. My systems which don't run systemd are immune to these vulnerabilities.

No, you cannot run systemd without journald. Journald can forward messages to another syslog implementation. Its launch is even hardcoded into systemd very early in the boot process IIRC. The intent is to capture early log messages in memory inside journald before a writable /var is available.

Reply on news.ycombinator.com