On 20/08/2015 18:53, Colin Booth wrote:
I think only the socket part is fancy systemd-centric design
Oh, the protocol is complicated too. If I start to implement it, there's no stopping, and I'll be running behind systemd every time they add something to the protocol, which is exactly what I don't want to do.
The API is definitely more complicated than the s6 notification one, but it doesn't seem insurmountable. My solution is a bit racy, though I'd hope a socket puller would start faster than a daemon, scheduler whims or no.
You can enforce a non-race by synchronizing both processes, i.e. making the notification listener notify the notification sender that it is ready to receive a message. I'm not even joking. Notifiception is a thing with the wonderful systemd APIs.
Adjustments to modules, locale and hostname setting, re-seeding the random device. Basically everything that happens in the single-user boot stage on distro systems. For example, the udev init script does a lot of work that can't easily be un-done without a reboot.
I see. You could pull those out of the set of services managed by s6-rc and just run them sequentially at boot time, until s6-rc-update is out. -- Laurent
