Re: s6-rc - odd warn logging and a best practices question

From: Laurent Bercot <ska-skaware_at_skarnet.org>
Date: Thu, 20 Aug 2015 17:44:25 +0200

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

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC