[PATCH] init: Add handshake to poweroff/reboot for signal handler setup

[Deb McLemore]

When PID=0 in early kernel_init, PID=1 has a skeleton running, this detection is not

the Busybox /sbin/init, but a place holder for when the real Busybox /sbin/init is do_execve'd

and then the kernel flushes all the old process table information on the place holder of PID=1,

then the real Busybox /sbin/init starts its life all fresh from the do_execve, no state remains.


On 02/14/2018 06:49 AM, Denys Vlasenko wrote:
> On Wed, Feb 14, 2018 at 4:29 AM, Deb McLemore <debmc at linux.vnet.ibm.com> wrote:
>> On 02/13/2018 08:32 PM, Laurent Bercot wrote:
>>>> Even when process=1 is started, it still leaves a window when the
>>>> signal handler setup has not been completed.
>>>  Yes, but you can still use kill(pid, 0) to check whether init is
>>> ready to receive signals: doublefork a zombie and repeatedly kill it
>>> with signal 0. When you get -1 ESRCH, it means init has reapt the
>>> zombie, so it's in its reaping loop, and at that point you know it
>>> has installed its signal handlers.
>>>
>>>  See http://lists.busybox.net/pipermail/busybox/2017-October/085888.html
>>>
>>>  That's arguably uglier than using abstract sockets, but it can
>>> be done without modifying the init code at all.
>> From the original thread, we tried the suggestion, but when the do_execve is done from kernel_init
>>
>> for Busybox /sbin/init (to start PID=1) all process zombies are flushed (the usermode helper that kicks
>>
>> Busybox /sbin/poweroff started by PID=2, before PID=1 is do_execve'd from kernel init).  So when the line is crossed
>>
>> when PID=1 begins all zombies and pre-work are flushed, so nothing is carried over into the life of PID=1
>> to synchronize with or detect when the signals are properly setup.
> You can detect this: before init is started, kill(1,0) should be giving ESRCH.
> Thus: first wait for kill(1,0) to return 0.
> Then, do a child reaping test. Or just sleep(1). :]
>