Re: Suggestions for --install

2017-10-11 Thread Denys Vlasenko
On Thu, Oct 5, 2017 at 9:31 PM, Christoph Biedl wrote: > ... the (for me) awkward part is to embed this into the manpage if and > only if CONFIG_FEATURE_INSTALLER is set. This is still somewhat beyond > my knowledge of the busybox build and install system. Don't

Re: Race in reboot/poweroff path at init?

2017-10-11 Thread Ralf Friedl
Laurent Bercot wrote: That is true, I hadn't thought of abstract sockets, and it would work. However, changing the way poweroff signals init is a big change, and in particular, making init listen to a socket is very significant: you know need to multiplex reaping zombies with listening to

Re: Race in reboot/poweroff path at init?

2017-10-11 Thread Laurent Bercot
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

Re: Race in reboot/poweroff path at init?

2017-10-11 Thread Laurent Bercot
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

Re: Race in reboot/poweroff path at init?

2017-10-11 Thread 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