Re: s6 service 'really up' clarification

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Tue, 13 Jan 2015 11:03:40 +0100

On 01/13/15 02:46, Laurent Bercot wrote:
> On 13/01/2015 01:35, Olivier Brunel wrote:
>> My idea was that it would be made aware of it, basically adding a new
>> 'command' to its fifo, so what s6-notifywhenup would do is write 'U'
>> there, and supervise would then update its state and be the one emitting
>> the event. (notifywhenup taking not a fifodir but a servicedir then.)
>>
>> And for cases where one doesn't use notifywhenup, e.g. because there's
>> another way for the daemon to notify it's ready, then s6-svc could have
>> a -U to do what notifywhenup does: tell supervise to update the state &
>> emit the event U.
>
> No, I cannot do that. We can't have other processes messing with the
> readiness state, and adding -U to the s6-svc interface is going to
> accomplish exactly that. Users are wonderfully creative when it comes
> to using tools for a totally different purpose than what they were made
> for, and I want to make sure this does not happen.
> s6-svc is a tool to control the service, not to make s6-supervise store
> user-provided information. If we need to store user-provided information,
> it should be done another way.

Yeah I agree, and I originally didn't like this for the same reason.
However, I figured if supervise supports it when written to its control,
it might as well be in svc, if only for consistency, plus it would be
easier for cases where notifywhenup cannot be used and another mechanism
indicates the ready state.

However, whether or not this is supported in svc, I still think it is
the right thing to do: have supervise maintain that info in the
statusfile, and so all other s6-* tool be aware of that state properly.

Even though it might not come from the process/service directly, I feel
it still is service information, not user-provided information (even
though it is. But one could argue that something like a file "down" also
is, yet supervise uses it).


>> This might not always be useful/used, but it's there when needed and it
>> feels to me like the correct way to have this information (as opposed to
>> have e.g. other tool maintaining a "parallel" state on their own...).
>
> Well I maintain that this information is not relevant to s6-supervise,
> that only knows about up and down. s6-supervise can tell when the service
> becomes not ready, but it cannot tell when it becomes ready - that event
> can only be provided via the daemon itself, so another tool is needed
> anyway. I'm very reluctant to pass the information back to s6-supervise
> if it can be stored directly by this other tool.
>
> I'll probably just have s6-supervise unlink supervise/ready on event
> up or down, and have s6-notifywhenup create supervise/ready on readiness

Yeah but then either s6-* tools still don't actually known anything
about that ready state now, or they do simply by using another file
instead of the statusfile, which really is all that should be needed.

Besides, you say you don't want supervise to know about this, yet it
still has to maintain it. If it needs to remove the ready file whenever
the service goes down, it effectively means it is in charge of
maintaining that information, or only half in charge. The other half
being left to some other tool.
And now we can easily have tools thinking a service is ready because
there's a ready file, even though the even U was never emitted...
whereas if supervise handles it fully, not only removing but also
creating the ready file (or, then a flag in the statusfile) & emitting
the event, it's much simpler to get consistent behavior: it emits U when
updating the statusfile to ready, emits d when updating it to down. No
one simply creates/unlinks a file without a corresponding event, better
consistency.

> notification, so s6-notifywhenup needs to have write access to
> supervise/ but not to supervise/status. And for other tools, it's easy
> enough to touch a file.

Note that I never expected notifywhenup to write to the statusfile, but
the control fifo of supervise, the later doing the status update &
event. supervise/status would be written to only by supervise.
Received on Tue Jan 13 2015 - 10:03:40 UTC