Slashdot Mirror
Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
Is there scope for a less intrusive fork of SystemD?
OpenRC + Init seems to be the commonly referenced replacement. UselessD seems to be a more reactionary replacement, which is also often mentioned. I still can't see what's wrong with init scripts :)
Can one expect a re-write of all these daemons by a small team with no history of working on these applications to be anywhere near free of bugs?
Not likely.
"First they came for the slanderers and i said nothing."
Administrators dislike constraint based systems.
This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.
This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.
This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".
The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".
So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.
A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".
Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.
Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.
--
So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".
How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.
At this time it hangs on:
systemd[1]: Failed to run event loop: Invalid argument
systemd[1]: Failed to run mainloop: Invalid argument
systemd-logind[123]: Failed to enable subscription: Message did not receive a reply (timeout by message bus)
systemd-logind[123]: Failed to fully start up daemon: Connection timed out
The last time, at least a few months ago, I solved it by downgrading systemd from version 208 or so to the previous version. In the last update (of the rest of the system) dhcpd, sshd and probably others stopped working so I decided to update systemd as well and got the error above. The distro is Archlinux ARM.
My x86_64 installs work flawlessly, except sometimes when a program segfaults and journald decides to take a core for itself for a few minutes.
And as a result, when you do /etc/init.d/apache stop, apache stops. When you do /etc/init.d/apache start, (drumroll please), apacghe starts. Just exactly what he said.
That is exactly what systemd does, without all the hacks of the script. And with systemd I can finally be sure if Apache started or not, and I can put a dependency to (for example) mysqld, because most web sites are using MySQL as database. All of that is not possible without major hacks in Sysvinit.
Like "/usr/bin/systemctl apache start"?
add a helper app that runs the daemon in a cgroup and sticks around to manage it?
That is exactly what systemd is, but it does per default for all services. You can still use script hackery if you want to.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
365 days without a security patch. Does uptime make you more money than protecting your customer data?
FFS. What makes you think a server needs to reboot for patches? Your extensive Windows administration experience?
UNIX/Linux servers need to reboot for a kernel patch. Very rarely (maybe never?) should a system need to reboot for anything other than a kernel patch. The number of recent packages aside from the kernel that require this is growing and a stunningly distrubing trend (mostly related to systemd).
Now, when must a kernel patch be applied? When a security patch is applied that affects something exploitable from one of your publicly accessible services.
An example, bind running inside a chroot jail and an exploit that requires access to a file or handle outside the jail != kernel patch and reboot.
A kernel patch for a local privilege escalation exploitable as www user with apache listening publicly = patch the kernel and reboot.
See the difference? There have been probably hundreds of local privesc exploits since I started working with Linux that just did not apply, and we very safely ignored the patch. When one matters, it is applied and we reboot. I've had specialty boxes that went multiple years without the need to reboot. We are on two commercial grids with battery and generator power available. I reboot when necessary, but have 6 9's of uptime (discounting planned outages) and the reason it's only 6 is hardware failure. It's 5 9's *INCLUDING* the planned outages across about 150 servers.
Now, I actually support systemd. But a few things seriously turn me off about it.
1) It is almost viral in what it demands, incorporates, and forces to be installed.
2) It doesn't appear to be well planned, documented, or tested.
3) There's a lot of scary shit in the bugtracker that is still unresolved or even assigned (some more than a year old).
Now, I accept that systemd and the 1000 required subpackages (udev, dbus, avahi, the QRcode enabled http server, journactl, etc.) are under development and alpha software. I don't understand why my production servers are supposed to migrate there now. Fix the broken crap and we'll talk, but again - my fucking notebook stopped resolving without a reboot after a non-kernel patch. Fuck that in production. Message clear?