problem with running "kill -QUIT 1" from init

Aras Vaichas arasv at magtech.com.au
Fri Jan 30 02:25:23 UTC 2009


Denys Vlasenko wrote:
> Hmm. I see why it doesn't work: in init.c:
>
>         /* Now run everything that needs to be run */
>         /* First run the sysinit command */
>         run_actions(SYSINIT);
>         /* Next run anything that wants to block */
>         run_actions(WAIT);
>         /* Next run anything to be run only once */
>         run_actions(ONCE);
>         /* Redefine SIGHUP to reread /etc/inittab */
>         signal(SIGHUP, ENABLE_FEATURE_USE_INITTAB ? reload_signal : SIG_IGN);
>         /* Now run the looping stuff for the rest of forever */
>         ...
>
> See? SIGHUP handler is installed only after 'sysinit' and 'wait'
> actions have finished and and 'once' action was started
> (init doesn't wait for 'once' to finish).
>
> This was actually intended.
> Say, if sysinit has completed, and then wait
> script sent SIGHUP to init - what to do then?
> We can reload /etc/inittab, but what do we do?
> Start over from sysinit?
> Or ignore sysinit entries and run only wait?
> Or skip wait too?
>
> Author used the simplest solution: SIGHUP does not work
> in these actions at all.
>   
I understand. It is a chicken-and-egg situation, hard to know which one 
must come first.

> The solution could be to start a child, and then let sysinit
> script to exit, leaving child to run:
>
> ...
> /the/helper/script.sh &
> exit
>
> and in /the/helper/script.sh, you sleep for, say 2 seconds,
> and then do "kill -HUP 1" etc... At this time, init will react
> to SIGHUP.
>   
Yes, I did think of this. The problem is that the end of the rcS script 
eventually starts up our main application. This becomes another complex 
issue. It is best if the upgrade cycle begins and ends within the 
upgrade script.

Our major release is going to make use of the runsv system for almost 
everything, so many of these sorts of problems will disappear.

> why can't you just replace /etc/inittab and reboot?
Yes, that was my solution. A two-part install. I figure that a major 
upgrade release like this is a rare event, so making the user wait for 
another system reboot is acceptable.

Thank you for your time, I appreciate you taking a look and commenting 
on this procedure. This script will be used to upgrade, possibly, 1000+ 
systems all around the world so I have to know that it is 100% correct.  :)

Aras



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


More information about the busybox mailing list