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
Received on Thu Aug 20 2015 - 17:24:14 UTC