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

From: Colin Booth <>
Date: Thu, 20 Aug 2015 09:53:45 -0700

On Thu, Aug 20, 2015 at 8:44 AM, Laurent Bercot <> wrote:
> In that case, yes,
> "if { init } if { notification } daemon" is probably the best. It
> represents service readiness almost correctly, if "service" includes
> the initialization.
Cool. Not the most elegant but good to know I was on the right track.
>> 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 think only the socket part is fancy systemd-centric design, so
presumably a stupid subscript that takes socket messages and emits
s6-ftrig events could do the reverse of sdnotify_wrapper. I'm thinking
something like s6-ipcserver-socketbinder execing into a background'ed
puller to s6-ftrig-notify chain. The puller would be something like
s6-ftrig-wait but for generic file descriptors instead of fifo dirs
(this probably exists and if not should be reasonably easy), and
s6-ftrig-notify would handle the actual readiness alarm.

The API is definitely more complicated than the s6 notification one,
but it doesn't seem insurmountable. My solution is a bit racy, though
I'd hope a socket puller would start faster than a daemon, scheduler
whims or no.
> 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 ?
Adjustments to modules, locale and hostname setting, re-seeding the
random device. Basically everything that happens in the single-user
boot stage on distro systems. For example, the udev init script does a
lot of work that can't easily be un-done without a reboot.


"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 - 16:53:45 UTC

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