Why replace init?

[Scott James Remnant]

Something I've realised that hasn't been elaborated on at this point:

Why replace init?

Why not just run the daemon from the existing sysvinit system, like Sun
OMF and launchd actually do?


There's a simple answer to this one, and it comes down to service
supervision.

Those systems require that in order to supervise a service, that service
should not daemonise and fork off into the background.  This seems a bit
silly, as that's what all daemons do.

The reason they require this is because once the daemon has forked, and
its parent died, the supervisor process receives the SIGCHLD signal for
the dead parent but never receives a signal about the (unrelated) child.

So there's no way for the supervisor to know when the service being
supervised actually exits.


So who gets the SIGCHLD signal for the unrelated child when _it_ dies?
Not many people seem to know this one, but the answer is simple, init!

All processes who lose their parents are reparented to be children of
init.

So by replacing init (process #1) we still receive SIGCHLD signals for
services that daemonise themselves.

The only thing we need to is find the PID of the unrelated child; we can
do this either by reading a "PID file" if we're told about one, or by
looking at /proc/*/exe if we're not.

Obviously this is a little less elegant than simply wait()ing on the
daemon, but in practice it works just as well.


Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20060605/53dcf90f/attachment.pgp