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
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
