Re: s6 service 'really up' clarification

From: Patrick Mahoney <>
Date: Tue, 13 Jan 2015 14:45:25 -0600

On 2015-01-12 5:38 pm, Laurent Bercot wrote:

> On 12/01/2015 23:27, Patrick Mahoney wrote:
>> So, speculating, it seems that 's6-svwait -U' on a service that is
>> currently 'down' either waits forever, or returns when something
>> sends a 'U' event. But when the service is 'up' (but no U event ever
>> happened), 's6-svwait -U' returns immediately as if the service was
>> 'really up'.
> Yes, and I agree that is counter-intuitive and problematic, but I
> haven't come up with a good solution yet.

Hm, unfortunate for my current plans. For now I'll just use
's6-ftrig-wait' (in place of s6-svwait -U) and accept the race

I've also dropped my s6-notifywhenup-fswatch script as I don't know how
to guarantee that the 'fswatch' command is watching the file *before*
the service goes ahead and starts, potentially logging the 'ready' line
when fswatch isn't yet running (since fswatch is in a background{}).

I could be more clever about testing for the 'ready' file, but for now
I've reverted to a pipeline on the service (which has its own problems
but at least there's no race). I wrote a simple filter in shell (rather
than rigging up multiple commands with 'tee' and 'grep'). Roughly:

   pipeline -w { filter } fdmove -c 2 1 service

where 'service' is the long-running service, and 'filter' is a command
that copies its input to stdout, but also compares each line against a
regex, and if it matches, notifies ./event with U, then exec's into

> And adding an understanding of service readiness to s6-supervise would:
> - make no sense: it's a process supervisor, no matter what the process
> does.

You've put more thought into this than I have, but it would be very
convenient for certain things. (Though perhaps the hypothetical
dependency-manager-atop-process-supervisor obviates all this.)

For reference, my use case may or may not be odd, but I'm bringing up a
number of services including a database, preparing said database by
loading schemas and data, then running some tests that depend on the
suite of services. So I'm trying to use s6 to force the ordering of

   [ base services up ] --> [ configure database ] --> [ run tests ]

The run script of the 'configure database' step waits for the database
service to be ready, and the 'run tests' step waits for 'configure
database' to be ready.

> - be absolutely bloated and ugly, since there should be a feedback
> canal from
> the service to s6-supervise, and I really don't want to go there.

The service can exit(), which sends information back to s6-supervise.

> - That means s6-notifywhenup has to have write permissions to
> supervise/
> instead of simply read permissions. So, basically, s6-notifywhenup has
> to
> run as root. It's nothing complex, but it's still more root code that
> the
> admin has to trust.

What if s6-supervise provided the fd, much like s6-notifywhenup does, to
which some status info could be written? (Optional, for backward compat
only if 'statusfd' file is present in the service directory; of course,
having additional service states is likely not backwards compatible in
the first place).


Patrick Mahoney <>
Received on Tue Jan 13 2015 - 20:45:25 UTC

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