On 13/01/2015 11:03, Olivier Brunel wrote:
> 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.
It's simpler and to some extent cleaner to use another file than
supervise/status. It does not break compatibility with other supervision
suites. It keeps supervise/status process-focused, with no extra
information. It's a minor modification to the code.
> 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).
Down files are different: it's configuration. Readiness information is
*not* configuration.
> 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.
Yes. Only 3 programs need to be aware of it: s6-supervise,
s6-notifywhenup and s6-svwait.
> 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.
Yes, that's inevitable, since s6-supervise receives one half of the
notification and s6-notifywhenup receives the other half. Looping the
latter back to s6-supervise would only clutter things up.
> 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...
No, that cannot happen. If only s6-notifywhenup touches the
supervise/ready file, and only s6-supervise removes it, then the file
matches the readiness state exactly. Of course, there's always the
possibility that some program sees a ready file and the service just
died and s6-supervise simply has not cleaned up yet, but that is
what the libftrig and s6-svwait are for: avoiding that race condition.
s6-svwait should really be the only user interface here.
> 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.
I really don't want to involve the control fifo in something that is
not control.
--
Laurent
Received on Tue Jan 13 2015 - 15:35:42 UTC