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
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
