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
Received on Thu Aug 20 2015 - 15:44:25 UTC