On Thu, Aug 9, 2012 at 10:02 AM, Peter Stuge <pe...@stuge.se> 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 dbus. 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. Rich
