pid 1 design
On Thu, Aug 9, 2012 at 10:02 AM, Peter Stuge <firstname.lastname@example.org> wrote:
> Luca Barbato wrote:
>> Repeat after me: having your first process require anything more
>> than libc is stupid and dangerous.
> Why do you say?
> And why is libc different from other libraries, say libuuid or
> libext2fs? I mean: Why allow pid 1 to require libc, it could
> just be statically linked.
So, while I've had only positive (but limited) experiences with
systemd, I can understand the fundamental design concern with having a
complex process running as pid 1. If init dies, the kernel panics
(just boot your system with init=/bin/bash and type exit to see).
So, a simple init that is less likely to die is a good thing.
That said, init NEEDS to be able to communicate with other processes
if you don't want it to keep propping things up when you're trying to
shut the system down. This is usually done via signals (init can trap
them all at least on linux), but I believe there are other mechanisms
that have been used in traditional init implementations. It seems
like the big changes to systemd/etc are to allow it to communicate via
I'm not sure why having systemd be a monolithic PID=1 solution was
chosen - that is probably a better topic for their lists. Maybe a
more resilient solution would be to have an init as PID=1 that does
nothing but launch systemd and keep it propped up until it gets a
signal from systemd. However, that could have issues I'm just not
thinking of. That could be accomplished just by running the
traditional init and having a runlevel with just systemd in it, aside
from any issues not being PID 1 creates for systemd.