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?
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 connections. It's not hard, but it requires patching init significantly, reworking its control flow around an asynchronous event loop; and at that point you're just better off using a better pid 1 process (such as s6-svscan, which already does this - have you considered switching inits? ;)). And changes of that magnitude are pretty dangerous - I'm quite convinced there are some people relying on the "send a signal to init" mechanism and whose systems would break if that mechanism were changed. The "send a signal to init" mechanism is a good one, and does not fundamentally need to be changed; your problem is a readiness detection one, i.e. whatever mechanism you're using to tell init to shutdown, you can't use it before init is ready to handle it. And that's where abstract sockets can be useful: you can use abstract sockets as a simple synchronization mechanism. The easiest way to do it would be: when init has installed its signal handlers, it creates an abstract socket (close-on-exec, of course) and binds it - but does not listen to it and does nothing else with it). And poweroff checks for the presence of this socket by repeatedly attempting connect(). When errno changes from ENOENT to ECONNREFUSED, it means the socket has been created and init is now ready to receive signals. This requires minimal change to init and a small polling addition to poweroff - which I think is much better and safer than a heavy change to busybox's init. -- Laurent _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
