Hi Denys,

>>  - installing the signal handlers even earlier in init_main(). However,
>>    this will only reduce the window for lost events, rather than
>>    eliminating it; or
> 
> Sure, this should be done. How about this:
> --- a/init/init.c
> +++ b/init/init.c
> @@ -1064,6 +1064,12 @@ int init_main(int argc UNUSED_PARAM, char **argv)
>  #endif
> 
>      if (!DEBUG_INIT) {
> +        /* Some users send poweroff signals to init VERY early.
> +         * To handle this, mask signals early,
> +         * and unmask them only after signal handlers are installed.
> +         */
> +        sigprocmask_allsigs(SIG_BLOCK);
> +
>          /* Expect to be invoked as init with PID=1 or be invoked as linuxrc 
> */
>          if (getpid() != 1
>           && (!ENABLE_LINUXRC || applet_name[0] != 'l') /* not linuxrc? */
> @@ -1204,6 +1187,8 @@ int init_main(int argc UNUSED_PARAM, char **argv)
>              + (1 << SIGHUP)  /* reread /etc/inittab */
>  #endif
>              , record_signo);
> +
> +        sigprocmask_allsigs(SIG_UNBLOCK);
>      }
> 
>      /* Now run everything that needs to be run */
> 
> This covers code which opens and parses /etc/inittab,
> which can be slow (if storage is slow), and can make
> race realistic in real world.
> 
> Can you test whether this change makes the race go away in your case?

This looks good, but it's not going to completely fix the race - in some
cases, we've seen the 'poweroff' binary started before init.

>>  - using a synchronous channel to send the shutdown/reboot message
>>    between the poweroff/reboot helpers, rather than an asynchronous
>>    signal. Say, have init listening on a socket, allowing the poweroff
>>    binary to wait and/or retry.
>>
>> However, before I go down the wrong path here: does anyone have other
>> ideas that might help eliminating dropped poweroff/reboot events?
> 
> The test that processes are being reaped is a good idea.

OK, sounds like something we should experiment with.

Thanks for the input!

Cheers,


Jeremy
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to