When you use s6-notifywhenup, or any readiness notification helper
that is not the service's direct supervisor, there is still a small
race condition - which can only bite in a very, very pathological
case, when the stars align in an incredibly evil way and your
system's scheduler decides that it really hates you. But it's
theoretically still there.
I don't like it.
So I bit the bullet and implemented readiness support directly in
s6-supervise. Come at me, pathological cases.
Now, instead of using s6-notifywhenup, you write a fd number into
a "notification-fd" file in the service directory. s6-supervise
picks that file up when starting the service, and will read
notification messages (i.e. everything up to the first newline)
that the daemon writes to the specified file descriptor.
Quick upgrade HOWTO:
if you were using "s6-notifywhenup -d FD -- foobard" before,
run "echo FD > notification-fd" in your service directory, and
just use "foobard" in your run script now.
Special annoying case: if FD is 1, i.e. the default, and your
service is logged, you'll want to do the following instead:
"echo 3 > notification-fd", and then use "fdmove 1 3 foobard" in
your run script. (Because the notification pipe will conflict with
the logging pipe otherwise.)
The feature is available in the latest s6 git head, which is also
a release candidate for 2.1.4.0. Please test the feature and send
your comments. If no bugs or immediate improvements are found, I'll
make the release soon.
--
Laurent
Received on Mon Jun 15 2015 - 19:29:13 UTC