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.
> 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
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.
--
Laurent
Received on Tue Jan 13 2015 - 01:46:46 UTC