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
