On 20/08/2015 16:43, Colin Booth wrote:
Yeah, this is for the special case where you have a daemon that
doesn't do readiness notification but also has a non-trivial amount of
initialization work before it starts. For most things doing the below
talked about oneshot/longrun split is best, but sometimes you need to
run that initialization every time (data validators are the most
obvious example).
In that case, yes,
"if { init } if { notification } daemon" is probably the best. It
represents service readiness almost correctly, if "service" includes
the initialization.
It does provide notification, but only if you're running under
systemd. At least according to the sd_notify() docs. I'll see about
faking up the environment so sd_notify() is happy and report back.
systemd's notification API is a pain. It forces you to have a daemon
listening on a Unix socket. So basically you'd have to have a
"notification receiver" service, communicating with the supervisors -
which eventually makes it a lot simpler to integrate everything into
a single binary.
This API was made to make systemd look like the only possible design
for a service manager. That's political design to the utmost, and I
hate that with a passion.
I have a wrapper to make things work the other way (i.e. using
s6-like daemons under systemd), but a wrapper that would actually
understand sd_notify() notifications would be much more painful to
write.
Actually, the more I think about it, the less s6-rc-update will help
me avoid reboots in the short term since part of what I need to get
back is a pristine post-boot environment.
What do you have in that post-boot environment that would be different
from what you have after shutting down all your s6-rc services and
wiping the live directory ?
--
Laurent
