Race in reboot/poweroff path at init?

[Didier Kryn]

Le 11/10/2017 à 04:43, Jeremy Kerr a écrit :
> Hi Laurent,
>
> Thanks for the reply, good to get some conversation going here!
>
>>> - 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.
>>   That would not work either: you could receive the event before init
>> starts listening to the socket.
> That's OK, as the helper (/sbin/poweroff) has the opportunity to retry
> if the connect() fails (because init hasn't established the listening
> socket yet). The main difference is that the sender can detect failure,
> and retry if necessary.
>
> AF_UNIX sockets in the abstract namespace don't require a path bound to
> the filesystem, so perhaps they would be available early enough - or
> have I missed something there?
>
> [Non-Linux platforms may not support the same abstract namespace, so
> I'd need to implement a fallback there, but I don't (yet) know if this
> same race is relevant on those platforms...]
>
> I'd rather not just wear the race, as that means we've missed shutdown
> events, which is quite user-visible. The signal-after-reaped-grandchild
> approach seems okay too, if other methods aren't workable. Or even
> Tito's suggestion of a repeated signal, which has the advantage of a
> minimal change to code.
     There's the sigqueue() mechanism out there. From the man page, it 
seems it's essentially dedicated to send data together with the signal, 
but it also has a queueing mechanism implemented in the kernel. Wether 
this allows the message to be kept in the queue until the destination 
process unmasks it, this isn't written explicitely in the man, but maybe 
somebody knows it. Anyway your case is a perfect test bench.

     Didier