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
condition.
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
'cat'.
> 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
things:
[ 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).
Thanks,
--
Patrick Mahoney <pat_at_polycrystal.org>
Received on Tue Jan 13 2015 - 20:45:25 UTC