Re: Readiness notification exemplars
On Sat, Apr 04, 2020 at 09:29:04PM +, Laurent Bercot wrote: > > > Yes it sounds like I completely misread the earlier emails, sorry about > > that. Now, looking at http://skarnet.org/software/s6/notifywhenup.html, > > I'm probably not reading that quite right, but it seems to tie the > > proposal to the 'notifcation-fd' file in the service directory, making > > it a bit less general. > > The notification-fd file is for s6-supervise, i.e. s6's implementation > of a supervisor. It is meant to make the fd number configurable on the > supervisor side, to allow daemons to use whatever fd they choose. > > On the daemon side, you can use any option you like to tell the daemon > what fd it should write to. It has nothing to do with s6, and I have no > recommended policy for daemons. > > > > s6-log however uses the -d argument to pass the > > fd, so I'll go with that. > > -d works for s6-log and a few others of my programs. For others, -d > is already used for something else, so I use another option. > I really suggest you don't try to standardize a way to tell daemons > what fd to use. No method will be universal, there will always be > some obscure daemon that will conflict with it. > Right, I didn't mean -d specifically :) I just meant pass the fd# as a command line argument. thanks, -serge
Re: Readiness notification exemplars
Yes it sounds like I completely misread the earlier emails, sorry about that. Now, looking at http://skarnet.org/software/s6/notifywhenup.html, I'm probably not reading that quite right, but it seems to tie the proposal to the 'notifcation-fd' file in the service directory, making it a bit less general. The notification-fd file is for s6-supervise, i.e. s6's implementation of a supervisor. It is meant to make the fd number configurable on the supervisor side, to allow daemons to use whatever fd they choose. On the daemon side, you can use any option you like to tell the daemon what fd it should write to. It has nothing to do with s6, and I have no recommended policy for daemons. s6-log however uses the -d argument to pass the fd, so I'll go with that. -d works for s6-log and a few others of my programs. For others, -d is already used for something else, so I use another option. I really suggest you don't try to standardize a way to tell daemons what fd to use. No method will be universal, there will always be some obscure daemon that will conflict with it. -- Laurent
Re: Readiness notification exemplars
So the API would be - the thing that starts the daemon opens an fd N, the daemon accepts an argument "--ready-fd=N", daemon writes something to fd N when ready or just closes it Well it has to write something (and in the current version of the protocol it requires a newline) before closing, else there would be no telling the difference between readiness and death - which aren't quite the same thing :) But yes, that's the idea. Closing is even optional, but since the supervisor is allowed to stop reading as soon as it detects a newline, it makes no sense to keep the fd open after writing the newline. and the thing checking whether daemon is ready sees fd activity and starts things depending on the daemon? Yes. In the s6 model, the thing checking that the daemon is ready is the supervisor, and it reports readiness to anything that has subscribed (typically the service manager), which can then act accordingly. -- Laurent
Re: Readiness notification exemplars
On Fri, Apr 03, 2020 at 07:41:25AM +, Jonathan de Boyne Pollard wrote: > Serge E. Hallyn: > > > If making changes to daemons were going to palatable, [...] > > > > Clearly, it *is* palatable, given that a few people have been adding the > systemd mechanism to their programs for several years, now. Pierre-Yves Well both that and the less successfull upstart sigstop had the full force of popular distros behind them. Still I hope you're right, and maybe I'll go ahead and post some patches for a few daemons. > Ritschard's code and Cameron Norman's code come straight out of actual > service programs. > Serge E. Hallyn: > > > you are arguing for parsing stdout for a text message and/or using > > pidfiles (written to an fd) > > > > No, M. Bercot is not. Quite the opposite, in fact. The s6 readiness > mechanism demands *neither* pidfiles *nor* standard output. It's *any* file > descriptor (as defined by the service), and *just a linefeed* followed by > closing the descriptor. > > I'm nodding at almost everything M. Bercot is saying here, by the way. > > * http://jdebp.uk./FGA/unix-daemon-readiness-protocol-problems.html Yes it sounds like I completely misread the earlier emails, sorry about that. Now, looking at http://skarnet.org/software/s6/notifywhenup.html, I'm probably not reading that quite right, but it seems to tie the proposal to the 'notifcation-fd' file in the service directory, making it a bit less general. s6-log however uses the -d argument to pass the fd, so I'll go with that. thanks, -serge
Re: Readiness notification exemplars
On Wed, Apr 01, 2020 at 05:13:06PM +, Laurent Bercot wrote: > > > There are pros and cons, but you are arguing for parsing stdout for a > > text message and/or using pidfiles (written to an fd). > > I'm arguing for none of these things. > I'm arguing for daemons to write a newline to a fd of their choice, > which is hardly anything difficult. And hardly anything difficult for > a supervisor to implement (if you're going to say that it's "parsing Sorry, the week got away from me and I never replied. So the API would be - the thing that starts the daemon opens an fd N, the daemon accepts an argument "--ready-fd=N", daemon writes something to fd N when ready or just closes it, and the thing checking whether daemon is ready sees fd activity and starts things depending on the daemon? It does sound good.
