On Thu, Aug 20, 2015 at 10:24 AM, Laurent Bercot
<ska-skaware_at_skarnet.org> wrote:
>
> 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.
>
Sure. And I bet that listening for any message on the socket isn't
good enough since things might be chattery.
>
> 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.
>
NOW we're talking!
>
> 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.
>
Yeah, but then you get into that question of what you do with oneshots
that depend on longruns which are required for initialization... Like
I said, it's a bit of a mess but isn't any more of a mess than someone
who is doing early boot optimization in any other init. Once I've
sorted out all the timing issues (and I think I'm close) it should be
fine.
By the way, I've found a maybe-bug that, if real, is pretty severe.
`s6-rc -d change all ; some stuff ; s6-rc -u change all' has caused my
s6-init + s6-rc testbed system to remove the control pipe for my pid 1
s6-svscan. I need to make sure it wasn't something I did between
things, and to make sure it wasn't mucked up handling in various
scripts that I was running. I'm at work right now so I can't test it
out, but sometime in the next day or so I should have the cycles to
test it out.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Thu Aug 20 2015 - 20:16:40 UTC