Pending patches

[Rob Landley]

On Saturday 01 November 2008 06:41:04 Denys Vlasenko wrote:
> On Saturday 01 November 2008 07:40, Rob Landley wrote:
> > When I say that signaling PID 1 so it can quiesce and shutdown the system
> > for you is the easy way to do it right, I really am serious.
>
> Why then many people are coming here with "my reboot doesn't work" then?

A) because people boot with init=/bin/sh even though they built init into 
busybox, and then when they try to use shutdown it sends a signal to PID 1 
that gets ignored.  (One of the special things about PID 1 is that its 
default handler for all signals is SIG_IGN, including kill -9.)

B) because it used to be really buggy, circa 1.1.x and earlier.

C) because the method of signaling init isn't quite standardized and they mix 
and match shutdown and init commands between busybox and non-busybox (the two 
have to agree on whether they're signalling via kill or whether they're 
signalling via /dev/initctl, or something else entirely.)  This is sort of a 
special case of (A), really.

Basically our shutdown should be able to figure out that it didn't 
successfully signal init and at least give an error message.  Unfortunately, 
there's no inherent response to signals back to the sending process.  (This 
is one of the reasons /dev/initctl was invented.)

> init authors (and I am speaking not only about bbox init,
> but sysV one too) didn't even manage to come to a coherent solution
> HOW to signal init! IIRC SysV init has a fifo (!) which you can talk into.
> How stupid - now suddenly you require a place in fs where that fifo
> might be created. bbox init uses signals.

And if you booted with init=/bin/sh and it hasn't registered a handler for 
that signal, then it gets silently ignored and your shutdown silently fails 
and you get an email asking why.

At least with the fifo, you can see it's not _there_ and maybe tell the user 
("can't signal init, try reboot -f").

> If I write "portable" reboot (one which does not know what kind
> of init is on the system), what should I do? Use signals?
> Or talk to /dev/initctl? Or both?

Generally you fallback from /dev/initctl to sending the signal, but warn when 
doing it so that the user may need to use shutdown -f.  (Or else wait a while 
and then do the force shutdown yourself, on the theory that init will kill 
you before then if it's working.)

Generally shutdown scripts do a killall -TERM, letting all the daemons know to 
save state and exit, waits a few seconds, then do a killall -9, and then 
quiesce the rest of the system.  How this interacts with network mounts is a 
problem for shutdown script writers...

How long to wait is, of course, one of those big imponderables...

> --
> vda

Rob