Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[psychoticmeow]

I maintain a branch of the Runit process supervision system, to which I've been enhancing it to allow it to act as a complete service manager that can replace rc.d/init.d. PID 1 is 350 lines of code. It has few functions: it must handle signals, reap zombies, start the service scanner (which itself starts supervisers for services, who start the services - see how we avoid putting too much functionality in one process?), and poweroff the system on request. Anything else is extraneous.

My point was that to get the functionality of systemd, it's already as minimal as it can be, not that other products cannot be more minimal. If anyone wishes to claim that something is less secure, then they need to provide evidence to back up their claim, baseless assertions are not facts.

[linuxradio]

I maintain a branch of the Runit process supervision system, to which I've been enhancing it to allow it to act as a complete service manager that can replace rc.d/init.d. PID 1 is 350 lines of code. It has few functions: it must handle signals, reap zombies, start the service scanner (which itself starts supervisers for services, who start the services - see how we avoid putting too much functionality in one process?), and poweroff the system on request. Anything else is extraneous.

I actually installed Dragora GNU/Linux-libre earlier, and it uses Runit, which I was quite satisfied with. I really hope that distro continues improving, and provides a good showcase for Runit on GNU/Linux. Also, I have to say this systemd anger is just silly. I'm using Parabola (an Arch derivative) with OpenRC pulled in from the AUR and KDE, and OpenRC is still mainanted for Debian for that matter. https://wiki.debian.org/OpenRC It's even the init system for Debian GNU/Hurd! Red Hat and GNOME can push systemd all they like, there are plenty of viable alternatives and distros that support them. If you don't like systemd, don't use a DE or distro that only supports it, problem solved. Don't get me wrong, I'm no systemd fan myself, but this idea that Red Hat can force it on all Linux users (or that we suddenly have to go running to FreeBSD as a result) is ridiculous.

[erendorn]

1. The performance gains of systemd are far outclassed by the complexity and insecurity drawbacks of it. Security has a multitude of approaches, but I like to approach it by taking a single point of failure caused by a monolithic program or process and break it up into several small programs. This reduces the attack surface from a huge monolith to a bunch of ants, more or less. The issue is, I don't like that systemd handles a good deal of unnecessary things in PID 1. This means a security exploit in those routines or roles can spread to the role of init, which means your machine or server is toast. BSD has an init system ( no, not BSD- style sysvinit ) which does the absolute bare minimum needed: starting and stopping the system from a set of run commands and handles zombie processes. Windows has the exact same issue, everything process related is handled by only a few programs, and need I say how many security exploits target their equivalent of init? Needless complexities are why OpenBSD and the other BEDs like FreeBSD would not want systemd even if it was portable.

Systemd project is made of 70+ binaries.
The process running in PID 1 is like 5ko.

[xeekei]

The reason systemd can't spin of it's process manager into a seperate process, is because the point is that every process and its children are supposed to be put in seperate cgroups. Let's say PID1 is only "init" like people suggest, that only starts and stops processes. The only process it can really start would be PID2, the cgroup manager, and then PID2 becomes the new master parent for the rest of the system. And all of a sudden BOTH PID1 and PID2 will bring down the system if they crash. Systemd is as minimal as it can get while still providing the functionality that they want it to provide.

[prodigy_]

Going by the above, it's doubtful you ever even attempted a serious and productive discussion.

Believe me (or not) I did. Nobody is listening. Then again, no forum discussions here will change a thing anyway. So what exactly do you suggest? That I go to the freedesktop.org mailing list and tell them they should throw the entire systemd concept out of the window? They're so going to listen.

The worst thing about systemd is that it's a problem that has no viable solution. Red Hat is behind it, so they'll do anything to help spread the disease. Gnome is hooked on it in more than one way now and distros are hooked on Gnome because it used to be THE thing. Nevermind that Gnome 3 has little to nothing in common with Gnome 2. It's brand that matters. Debian is pseudo-democracy hijacked by systemd developers. Ubuntu is hooked on Debian and Mint is hooked on Ubuntu. Arch guys simply said "whatever" and went with the flow.

Only Gentoo remains as the last bastion but it won't stand for long.

If you had good technical arguments and presented them in a good manner, I'm sure people would be open to them.

The sad fact is that people can't do squat about systemd whether they listen or not. And Red Hat obviously won't do anything because everything is going excactly as they planned.

[V10lator]

I maintain a branch of the Runit process supervision system, to which I've been enhancing it to allow it to act as a complete service manager that can replace rc.d/init.d. PID 1 is 350 lines of code. It has few functions: it must handle signals, reap zombies, start the service scanner (which itself starts supervisers for services, who start the services - see how we avoid putting too much functionality in one process?), and poweroff the system on request. Anything else is extraneous.

A few questions that come to my mind:

• You have most likely more code than if these processes where one. So the maintenance burden is higher, right?
• Cause you have more code you might even have more bugs, no?
• Instead of giving a potential attacker PID 1 has a target he can now inspect PID 1, PID 2, ... cause they are all highly privileged processes. How exactly is that more secure?
• What happens if PID 2 crashes? Does PID 1 monitor it and terminates when that happens? If not: How does the kernel know that the init system has crashed?

[JX8p]

A few questions that come to my mind:

• You have most likely more code than if these processes where one. So the maintenance burden is higher, right?
• Cause you have more code you might even have more bugs, no?
• Instead of giving a potential attacker PID 1 has a target he can now inspect PID 1, PID 2, ... cause they are all highly privileged processes. How exactly is that more secure?
• What happens if PID 2 crashes? Does PID 1 monitor it and terminates when that happens? If not: How does the kernel know that the init system has crashed?

1. A bit more code, yes. But I would say the maintenance burden is lesser. The implementation is a bit more work - this is a trade off for simpler maintenance.
2. Well, any more code has the potential of introducing bugs. However, I think separate, simpler processes as opposed to a more complex single one tend to be less buggy. As well as that, my branch of Runit does not even allocate any heap memory in the init process, nor the service scanner.
3. PID 2, which is the service scanner, is not necessarily invulnerable to exploitation. But it's simple and exposes only a few interfaces, so I don't think it's too likely that there is a security issue.
4. Init (PID 1) has a simple fork-exec-wait-repeat mechanism, which will relaunch the service scanner (PID 2) if it dies. Though, like I say, it shouldn't die - the code is simple enough that I can see no potential cause.

[curaga]

The reason systemd can't spin of it's process manager into a seperate process, is because the point is that every process and its children are supposed to be put in seperate cgroups. Let's say PID1 is only "init" like people suggest, that only starts and stops processes. The only process it can really start would be PID2, the cgroup manager, and then PID2 becomes the new master parent for the rest of the system. And all of a sudden BOTH PID1 and PID2 will bring down the system if they crash. Systemd is as minimal as it can get while still providing the functionality that they want it to provide.

No, unless my understanding of cgroups is wrong. PID 1 dies = kernel panic. Cgroup handler dies? Existing apps are not affected. That's a rather large difference to me.

[RahulSundaram]

No, unless my understanding of cgroups is wrong. PID 1 dies = kernel panic. Cgroup handler dies? Existing apps are not affected. That's a rather large difference to me.

This isn't correct. If systemd dies, it just freezes and doesn't crash anything. You cannot start/stop services but the existing services will continue running.

[Gusar]

That I go to the freedesktop.org mailing list and tell them they should throw the entire systemd concept out of the window?

That is neither serious nor productive.

Debian is pseudo-democracy hijacked by systemd developers.

Debian's governing bodies and procedures are written down in their constitution. Deciding on the default init system was just following the processes according to that constitution, there was no "hijacking" or anything. Especially not by systemd developers, Russ Allbery and Bdale Garbee, the strongest systemd supporters on the technical committee, are not systemd devs.

Arch guys simply said "whatever" and went with the flow.

systemd in Arch was baking for about two years. In that time, the Arch devs found quite a few things lacking in systemd or wanted some things done differently, so they went to the mailing list and discussed it, often provided the implementation themselves. So no, the Arch devs did not "go with the flow", they were active participants in helping systemd mature and didn't switch the distro over until they felt systemd has reached sufficient maturity. This can be seen in the release announcements for systemd, which often contain the names Tom Gundersen, Dave Reisner and Thomas B?chler, all Arch devs.

You say you tried serious discussions, but from the things you write now, and especially the way you write them, I don't see it. Writing about "diseases", "hijacking" and "bastions"... while you don't go directly into conspiracy theories like some others do, you're not that far away.