On 01/13/15 00:38, 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. > > The issue is that s6-supervise stores the service state in > supervise/status > and has no notion of service readiness. For s6-supervise, either the > service > is up (pid nonzero) or it is down (pid zero), it cannot know whether the > service is "really up" or not. > 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. > I use it for cron-like jobs (do the job then sleep for a while), for > instance, > where there's no notion of service readiness. > - 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.
If I may... this is actually something I have been thinking about, and was planning on suggesting: that supervise should be aware of that 'U' state. 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. That way s6-svwait or s6-svstat could also be aware of the U state properly, since it would in fact be in the statusfile, so there's always a proper/consistent state known to all s6-* tool. 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...). > s6-svwait listens on the event/ fifodir then checks on supervise/status to > know the initial state of the service before any notification arrives. But > that initial state is only "down" or "up", as s6-supervise wrote it; > it's never > "ready". So for now, s6-svwait -U assumes that "up" means "ready". Which > causes the behaviour you observed. > > To solve that, the up vs. ready state should be stored in another file, > that > s6-svwait -U should check. The logical place to do that operation is in > s6-notifywhenup.But that raises a few other issues: > > - That would more or less enforce s6-notifywhenup as *the* readiness > notification tool to use with s6-svwait. If daemons want to use another > notification mechanism than the one supported by s6-notifywhenup, there > will > need to be another compatibility tool to convert notification mechanisms. > This can become pretty ugly really fast. > > - 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. > > - s6-notifywhenup isn't around when the daemon dies, so it cannot update > the new state file. Only s6-supervise is around, so it has to do the job. > That is an ad-hoc hook that needs to be added to s6-supervise. Again, > nothing complex, but by definition, ad-hoc is ugly. > > All this is probably still better than the current behaviour, so I may add > it in a future release. >
