Which init system for Debian?

Posted Nov 13, 2013 13:44 UTC (Wed) by hummassa (subscriber, #307)
In reply to: Which init system for Debian? by smurf
Parent article: Which init system for Debian?

> (a) it does not know when a service is up
> (b) systemd's socket activation means that you can forget about many dependencies as they simply do not matter any more
> (c) socket activation also means that you can seamlessly restart a service, a feat which is impossible with Sys5-

> I'm not going to rehash all the other neat features which are impossible (or very difficult) with SysV-init.

What no one else could explain to me, up to the present moment, is *why* do those things (which are neat, I agree) belong to the init process. Services infrastructure is great, but it does not need to be in init...

Which init system for Debian?

Posted Nov 13, 2013 14:20 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Why wouldn't you put this function there? In the design of the UNIX system, init clearly has the responsibility for starting and restarting processes, handling zombies and managing the lifecycle of the system. Sure, SysV init really can only handle managing TTYs directly, because that is what was most important when it was designed, but it seems clear to me that this is how the system is supposed to work, and that the whole /etc/init.d system is just a hack layered on top to handle the additional complexity of services that init doesn't have the functionality to handle.

That problem is now resolved.

Which init system for Debian?

Posted Nov 13, 2013 14:20 UTC (Wed) by HelloWorld (guest, #56129) [Link] (5 responses)

Why does anybody make a fuss about having a slightly bigger init daemon when we have a kernel that is tens or hundreds of times as big?

Which init system for Debian?

Posted Dec 5, 2013 12:54 UTC (Thu) by malor (guest, #2973) [Link] (4 responses)

In my case, attack surface, mostly.

I would rather see truly separate programs to accomplish all the things that systemd is putting its tentacles into, because the chance of a system-compromising bug goes up at a rough square with the number of features on offer within the same binary. Every feature added to a program has a chance of interacting poorly with every other feature.

Putting things into separate binaries, with clearly defined, published interfaces, makes reasoning about and preventing security issues far, far easier.

And, from a security standpoint, the Linux kernel sucks, so there is an existing, very real reason to distrust the mega-feature approach to programming.

Which init system for Debian?

Posted Dec 5, 2013 13:29 UTC (Thu) by micka (subscriber, #38720) [Link]

Then there's no problem, because systemd is multiple separate binaries.

It's strange, I think this remark has already been done, with the same answer...

Which init system for Debian?

Posted Dec 5, 2013 13:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Systemd *is* a lot of binaries. Check out the tab completion on `system<Tab>`. Even so, the tradeoff for lots of binaries is that now IPC is a problem if they're long running. If you get too many, now you have to validate the parsers of the IPC endpoints as well. At some point relying on the C compiler for checking arguments and such gets to be much easier there. The problem is usually in finding that line.

Which init system for Debian?

Posted Dec 5, 2013 17:24 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

systemd is a bunch of separate binaries, but instead of a well defined interface between them, the interface is whatever this version of systemd decides to make it, with the next version free to change everything.

Which init system for Debian?

Posted Dec 5, 2013 17:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Hmm? Systemd is pretty good about documenting their interfaces[1] and keeping backwards compatibility[2]. If you stray from the defined interfaces, then yeah, you might find some landmines. Which APIs are you referring to being in flux? Anything related to D-Bus[3]?

[1]http://www.freedesktop.org/wiki/Software/systemd/Interfac...
[2]http://upstream-tracker.org/versions/systemd.html
[3]http://www.freedesktop.org/wiki/Software/systemd/dbus/

Which init system for Debian?

Posted Nov 13, 2013 19:13 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

You need *some* long-running "Job Manager" process which collects dependency information, manages control groups, decides what to start and stop and restart, and whatnot.(*)

PID 1 gets all the SIGCHLD notifications about dead processes. If it has to forward that information to the Job Manager, you get race conditions which are basically unfixable. Therefore init needs to be the Job Manager.

The question I like to ask whenever that comes up is "is there any advantage to moving this problem space to some other process?" So far I haven't seen any better reason than "init is supposed to be small" – which does not make sense because need the features anyway, so whether they're covered by one process or ten doesn't matter and consumes roughly the same amount of RAM.

(*) "need" in the sense of "I know that sysv-init doesn't have such a process, but it also doesn't have [ insert basically any systemd feature ], which I *want*, and which cannot reasonably be implemented without some management process, so …"

Which init system for Debian?

Posted Nov 15, 2013 18:59 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

PID 1 gets all the SIGCHLD notifications about dead processes.

Actually it gets a basically random subset: that from processes whose parents have died. (Of course, if the parents haven't died, they should be cleaning things up...)

It is clear, though, that this decision was originally made explicitly so that init could do exactly the sort of respawning and tidying up job that sysvinit is so manifestly bad at.

Which init system for Debian?

Posted Nov 15, 2013 20:52 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

It is part of the initialisation protocol for Unix processes implementing background services to have themselves adopted by the init process just to make sure that the init process is notified when they exit.

That SysV init hasn't been doing anything with that information for the last 30 years or so is only too bad – but then again if you don't even know who your kids are in the first place, what are you going to do when they kick the bucket? Yay for systemd.

Which init system for Debian?

Posted Nov 15, 2013 23:50 UTC (Fri) by nix (subscriber, #2304) [Link]

... though, of course, if this information was actually useful systemd would be able to use it rather than cgroups.

What we really need is an option (inherited or systemwide, it doesn't matter) forcing *all* SIGCHLDs to go to PID 1, even if they also go to their real parent. But this is hard to implement in practice because the first thing you do on receipt of a SIGCHLD is reap the child, and you can't have two processes reaping the same child... not even a hack where PID 1's reap doesn't actually make the child go away if it has a live parent would work (the live parent could get to it first, leaving PID 1 with nothing to see).

Gah. Everything around child process management in Unix is just a horror. No wonder ptrace(), which builds on it in a halfwitted and agonizing fashion and has just the same problem with a process with 'two parents', is so horrible to use.