* Readiness notification exemplars @ 2020-04-01 13:23 Brett Neumeier 2020-04-01 13:36 ` Casper Ti. Vector ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Brett Neumeier @ 2020-04-01 13:23 UTC (permalink / raw) To: Supervision [-- Attachment #1: Type: text/plain, Size: 590 bytes --] I read on http://skarnet.org/software/s6/notifywhenup.html: "...daemons can simply write a line to a file descriptor of their choice, then close that file descriptor, when they're ready to serve. This is a generic mechanism that some daemons already implement." I am curious, does anyone on this list know of examples of such daemons? I am considering creating and submitting patches for some daemon programs that I use that do *not* support this mechanism as yet, and am curious if it is as simple as it looks like it should be. Cheers! Brett -- Brett Neumeier (bneumeier@gmail.com) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 13:23 Readiness notification exemplars Brett Neumeier @ 2020-04-01 13:36 ` Casper Ti. Vector 2020-04-01 14:21 ` Serge E. Hallyn 2020-04-01 14:55 ` Laurent Bercot 2 siblings, 0 replies; 18+ messages in thread From: Casper Ti. Vector @ 2020-04-01 13:36 UTC (permalink / raw) To: supervision On Wed, Apr 01, 2020 at 08:23:26AM -0500, Brett Neumeier wrote: > I am curious, does anyone on this list know of examples of such daemons? I > am considering creating and submitting patches for some daemon programs > that I use that do *not* support this mechanism as yet, and am curious if > it is as simple as it looks like it should be. s6-log for example? Not claimed to be a daemon, but generally used as one: <https://git.skarnet.org/cgi-bin/cgit.cgi/s6/tree/src/daemontools-extras/s6-log.c>. (Search for `notif' in the file; yes, it is indeed very simple to implement.) -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 13:23 Readiness notification exemplars Brett Neumeier 2020-04-01 13:36 ` Casper Ti. Vector @ 2020-04-01 14:21 ` Serge E. Hallyn 2020-04-01 15:06 ` Laurent Bercot 2020-04-01 14:55 ` Laurent Bercot 2 siblings, 1 reply; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-01 14:21 UTC (permalink / raw) To: Brett Neumeier; +Cc: Supervision I've been considering for several years trying to push a kernel patch which would provide a way for userspace to find out when someone starts listening on some port. Based on problems I saw long ago in the late days of upstart and early days of systemd, that seemed like it would solve a not infrequent problem without having to make any changes to the daemons. Upstart tried to solve it by making the daemons send a sigstop when ready; systemd solves it by making the daemons support socket notification; listen-notifiers could be entirely handled by the dependency handler in the init system. It's *still* on my list of todos. Maybe sufficient ridicule here will help me knock it off the list :) On Wed, Apr 01, 2020 at 08:23:26AM -0500, Brett Neumeier wrote: > I read on http://skarnet.org/software/s6/notifywhenup.html: > > "...daemons can simply write a line to a file descriptor of their choice, > then close that file descriptor, when they're ready to serve. This is a > generic mechanism that some daemons already implement." > > I am curious, does anyone on this list know of examples of such daemons? I > am considering creating and submitting patches for some daemon programs > that I use that do *not* support this mechanism as yet, and am curious if > it is as simple as it looks like it should be. > > Cheers! > > Brett > > -- > Brett Neumeier (bneumeier@gmail.com) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 14:21 ` Serge E. Hallyn @ 2020-04-01 15:06 ` Laurent Bercot 2020-04-01 15:28 ` Serge E. Hallyn 0 siblings, 1 reply; 18+ messages in thread From: Laurent Bercot @ 2020-04-01 15:06 UTC (permalink / raw) To: Supervision >I've been considering for several years trying to push a kernel patch >which would provide a way for userspace to find out when someone starts >listening on some port. Based on problems I saw long ago in the late >days of upstart and early days of systemd, that seemed like it would >solve a not infrequent problem without having to make any changes to >the daemons. First you'd have to make sure that the cure isn't worse than the problem. What mechanism would the kernel use to notify userspace that a given program has started listening on a port? Wouldn't that add significant complexity to supervisors? And then I think there's a fundamental design problem: how would a generic supervisor handle this? For instance, s6-supervise doesn't know (and isn't supposed to know) what its child does. If the kernel sends it a notification that the child is now listening on port 80, how can it be sure that the child is ready? - Maybe the child is also going to open port 443 (but it's taking some time because it's busy reading its TLS keys), and will only be ready after both 80 and 443 are open. - Maybe the child isn't a web server at all, is just making a temporary transaction on port 80 and will only be ready after some other operation, after the transaction has taken place. Readiness isn't as simple as listening to a port. It can be about allocating any number and any kind of resources. It is possible that listening to ports has no relation to readiness at all. Only a daemon can know when it's ready; the kernel cannot guess it. So you simply won't be able to solve the problem without making any changes to the daemons. -- Laurent ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 15:06 ` Laurent Bercot @ 2020-04-01 15:28 ` Serge E. Hallyn 2020-04-01 15:59 ` Laurent Bercot 0 siblings, 1 reply; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-01 15:28 UTC (permalink / raw) To: Laurent Bercot; +Cc: Supervision On Wed, Apr 01, 2020 at 03:06:49PM +0000, Laurent Bercot wrote: > > I've been considering for several years trying to push a kernel patch > > which would provide a way for userspace to find out when someone starts > > listening on some port. Based on problems I saw long ago in the late > > days of upstart and early days of systemd, that seemed like it would > > solve a not infrequent problem without having to make any changes to > > the daemons. > > First you'd have to make sure that the cure isn't worse than the > problem. What mechanism would the kernel use to notify userspace that > a given program has started listening on a port? Wouldn't that add > significant complexity to supervisors? pollable fd that you can add to your epoll set. > And then I think there's a fundamental design problem: how would a > generic supervisor handle this? For instance, s6-supervise doesn't know > (and isn't supposed to know) what its child does. If the kernel sends it > a notification that the child is now listening on port 80, how can it be > sure that the child is ready? You'd have to buy into it with a syscall that says "let me know when something listens on tcp port N". In turn s6-supervise would only do that if some config said "don't start service Y until something (which is expected to be service X) proves it's ready by listening on port N". The idea was to handle cases like libvirt being ready to accept VM managing requests. > - Maybe the child is also going to open port 443 (but it's taking some > time because it's busy reading its TLS keys), and will only be ready > after both 80 and 443 are open. Then wait until both. > - Maybe the child isn't a web server at all, is just making a temporary > transaction on port 80 and will only be ready after some other operation, > after the transaction has taken place. Then don't use this. > Readiness isn't as simple as listening to a port. It can be about Sometimes it is. > allocating any number and any kind of resources. It is possible that > listening to ports has no relation to readiness at all. > Only a daemon can know when it's ready; the kernel cannot guess it. > So you simply won't be able to solve the problem without making any > changes to the daemons. Not all of it. But it appears to me the whole world gave into systemd for the sake of socket activation, and in my time handling upstart service dependency for ubuntu server, availability over the network was the most common, perhaps even the only, usable metric. Mind you I'm certainly open to the idea that maybe this isn't worth doing - else I'd have actually implemented it by now :) But so far I've not seen anything that seems as good, let alone better. -serge ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 15:28 ` Serge E. Hallyn @ 2020-04-01 15:59 ` Laurent Bercot 2020-04-01 16:26 ` Serge E. Hallyn 0 siblings, 1 reply; 18+ messages in thread From: Laurent Bercot @ 2020-04-01 15:59 UTC (permalink / raw) To: Supervision >You'd have to buy into it with a syscall that says "let me know when >something listens on tcp port N". In turn s6-supervise would only do >that if some config said "don't start service Y until something (which >is expected to be service X) proves it's ready by listening on port N". >The idea was to handle cases like libvirt being ready to accept VM >managing requests. Yes, so it's not only about adding a pollable fd to a fd set, it's also telling the kernel what kind of notifications you're interested in receiving. So that means: for the supervisor, designing and parsing a config file; for the service writer, writing a supervisor-specific config file. You added complexity to the supervisor, made it more difficult to change supervisors by locking in service config files, added burden to packagers, and turned a two-way transaction into a three-way one (that now includes the kernel). All this to achieve one benefit: make no changes to daemons. It seems very much not worth it. Also, "Don't start service Y until something is ready" is not the supervisor's job, it's the service manager's. The supervisor only reports service readiness; the service manager can make use of it if needed. If your mechanism assumes that the supervisor and the service manager are one and the same program, it enforces a monolithic design - systemd people will love it, but I won't. >Not all of it. But it appears to me the whole world gave into systemd >for the sake of socket activation Yeah, based on propaganda and hype. Doesn't mean it's good tech, and I don't understand the urge to add to the problem. >and in my time handling upstart >service dependency for ubuntu server, availability over the network was >the most common, perhaps even the only, usable metric. It's just a question of setting up IPCs. It's only important to know when a service is ready because you want to communicate with that service, so in theory you could exhaustively list all existing IPC mechanisms (of which inet domain sockets would be the most common), and make it work that way. I still don't think it would be a good idea. >Mind you I'm certainly open to the idea that maybe this isn't worth >doing - else I'd have actually implemented it by now :) But so far I've >not seen anything that seems as good, let alone better. I'm looking at the total amount and distribution of effort. Adding s6-style readiness notification to an existing daemon is like 4 lines of code, and the effort is trivially distributed, so it's easy. (And running such a daemon under another supervisor is also easy, see sdnotify-wrapper.) Your proposal requires - adding stuff to the kernel: significant effort for kernel devs - forcing supervisors to add config options to support it: significant effort for supervisor devs, and breaks cross-OS portability - forcing distros to add config options to enable it: small amount of effort, easily distributed - the only people it doesn't impact is daemon code maintainers - the kernel is now involved in something that could be handled in a pure userland way with existing mechanisms So, how much has the daemon code maintainers lobby paid you, and how can I get a share of it? :P -- Laurent ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 15:59 ` Laurent Bercot @ 2020-04-01 16:26 ` Serge E. Hallyn 2020-04-01 17:13 ` Laurent Bercot 2020-04-03 7:41 ` Jonathan de Boyne Pollard 0 siblings, 2 replies; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-01 16:26 UTC (permalink / raw) To: Laurent Bercot; +Cc: Supervision On Wed, Apr 01, 2020 at 03:59:25PM +0000, Laurent Bercot wrote: > > You'd have to buy into it with a syscall that says "let me know when > > something listens on tcp port N". In turn s6-supervise would only do > > that if some config said "don't start service Y until something (which > > is expected to be service X) proves it's ready by listening on port N". > > The idea was to handle cases like libvirt being ready to accept VM > > managing requests. > > Yes, so it's not only about adding a pollable fd to a fd set, it's > also telling the kernel what kind of notifications you're interested > in receiving. So that means: for the supervisor, designing and parsing > a config file; for the service writer, writing a supervisor-specific > config file. > > You added complexity to the supervisor, made it more difficult to > change supervisors by locking in service config files, added burden to > packagers, and turned a two-way transaction into a three-way one (that > now includes the kernel). All this to achieve one benefit: make no > changes to daemons. It seems very much not worth it. Yes. If making changes to daemons were going to palatable, then an explicit "I am ready" API would be best. That still would require the same changes to the service managers. But it would be unambiguous. > Also, "Don't start service Y until something is ready" is not the > supervisor's job, it's the service manager's. The supervisor only > reports service readiness; the service manager can make use of it if > needed. If your mechanism assumes that the supervisor and the service > manager are one and the same program, it enforces a monolithic design - > systemd people will love it, but I won't. Don't think that should matter here. When those are separate then the service manager can do it all. > > Not all of it. But it appears to me the whole world gave into systemd > > for the sake of socket activation > > Yeah, based on propaganda and hype. Doesn't mean it's good tech, and > I don't understand the urge to add to the problem. There are pros and cons, but you are arguing for parsing stdout for a text message and/or using pidfiles (written to an fd). The former is bad because stdout text changes as code evolves. The latter is bad as you've mentioned because pidfile ready != service ready. > > and in my time handling upstart > > service dependency for ubuntu server, availability over the network was > > the most common, perhaps even the only, usable metric. > > It's just a question of setting up IPCs. It's only important to know > when a service is ready because you want to communicate with that > service, so in theory you could exhaustively list all existing IPC > mechanisms (of which inet domain sockets would be the most common), > and make it work that way. I still don't think it would be a good idea. It might not be. I'm still looking for good reasons why it wouldn't be. > > Mind you I'm certainly open to the idea that maybe this isn't worth > > doing - else I'd have actually implemented it by now :) But so far I've > > not seen anything that seems as good, let alone better. > > I'm looking at the total amount and distribution of effort. > Adding s6-style readiness notification to an existing daemon is like > 4 lines of code, and the effort is trivially distributed, so it's easy. > (And running such a daemon under another supervisor is also easy, see > sdnotify-wrapper.) > Your proposal requires > - adding stuff to the kernel: significant effort for kernel devs > - forcing supervisors to add config options to support it: significant > effort for supervisor devs, and breaks cross-OS portability > - forcing distros to add config options to enable it: small amount of > effort, easily distributed > - the only people it doesn't impact is daemon code maintainers > - the kernel is now involved in something that could be handled in a > pure userland way with existing mechanisms > > So, how much has the daemon code maintainers lobby paid you, and how > can I get a share of it? :P Yeesss, those sweet, deep, daemon code maintainer lobby pockets ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 16:26 ` Serge E. Hallyn @ 2020-04-01 17:13 ` Laurent Bercot 2020-04-04 15:02 ` Serge E. Hallyn 2020-04-03 7:41 ` Jonathan de Boyne Pollard 1 sibling, 1 reply; 18+ messages in thread From: Laurent Bercot @ 2020-04-01 17:13 UTC (permalink / raw) To: Supervision >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 stdout", then okay, but the parser fits in 20 lines of C). The fact that existing daemon behaviours can be used to trigger the mechanism without modification is a nice bonus that weighted in favor of that choice, but was hardly the only factor. >> I still don't think it would be a good idea. >It might not be. I'm still looking for good reasons why it wouldn't be. Well I just gave you a full e-mail of reasons why, if they're not good enough for you, I doubt anything will convince you. :P -- Laurent ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 17:13 ` Laurent Bercot @ 2020-04-04 15:02 ` Serge E. Hallyn 2020-04-04 15:54 ` Laurent Bercot 0 siblings, 1 reply; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-04 15:02 UTC (permalink / raw) To: Laurent Bercot; +Cc: Supervision On Wed, Apr 01, 2020 at 05:13:06PM +0000, 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-04 15:02 ` Serge E. Hallyn @ 2020-04-04 15:54 ` Laurent Bercot 0 siblings, 0 replies; 18+ messages in thread From: Laurent Bercot @ 2020-04-04 15:54 UTC (permalink / raw) To: Supervision >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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 16:26 ` Serge E. Hallyn 2020-04-01 17:13 ` Laurent Bercot @ 2020-04-03 7:41 ` Jonathan de Boyne Pollard 2020-04-04 15:48 ` Serge E. Hallyn 1 sibling, 1 reply; 18+ messages in thread From: Jonathan de Boyne Pollard @ 2020-04-03 7:41 UTC (permalink / raw) Cc: Supervision 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 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-03 7:41 ` Jonathan de Boyne Pollard @ 2020-04-04 15:48 ` Serge E. Hallyn 2020-04-04 21:29 ` Laurent Bercot 0 siblings, 1 reply; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-04 15:48 UTC (permalink / raw) To: Jonathan de Boyne Pollard; +Cc: Supervision On Fri, Apr 03, 2020 at 07:41:25AM +0000, 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-04 15:48 ` Serge E. Hallyn @ 2020-04-04 21:29 ` Laurent Bercot 2020-04-04 22:18 ` Serge E. Hallyn 0 siblings, 1 reply; 18+ messages in thread From: Laurent Bercot @ 2020-04-04 21:29 UTC (permalink / raw) To: Supervision >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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-04 21:29 ` Laurent Bercot @ 2020-04-04 22:18 ` Serge E. Hallyn 2020-04-07 23:03 ` Brett Neumeier 0 siblings, 1 reply; 18+ messages in thread From: Serge E. Hallyn @ 2020-04-04 22:18 UTC (permalink / raw) To: Laurent Bercot; +Cc: Supervision On Sat, Apr 04, 2020 at 09:29:04PM +0000, 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-04 22:18 ` Serge E. Hallyn @ 2020-04-07 23:03 ` Brett Neumeier 2020-04-08 11:02 ` Laurent Bercot 2020-04-09 10:31 ` Jonathan de Boyne Pollard 0 siblings, 2 replies; 18+ messages in thread From: Brett Neumeier @ 2020-04-07 23:03 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Laurent Bercot, Supervision [-- Attachment #1: Type: text/plain, Size: 487 bytes --] On Sat, Apr 4, 2020 at 5:18 PM Serge E. Hallyn <serge@hallyn.com> wrote: > > 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. > It's maybe a little heavy-handed, but is there any technical reason not to just pick an arbitrary FD, like say 3, and just always use that for a particular daemon? Cheers, Brett -- Brett Neumeier (bneumeier@gmail.com) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-07 23:03 ` Brett Neumeier @ 2020-04-08 11:02 ` Laurent Bercot 2020-04-09 10:31 ` Jonathan de Boyne Pollard 1 sibling, 0 replies; 18+ messages in thread From: Laurent Bercot @ 2020-04-08 11:02 UTC (permalink / raw) To: Supervision >It's maybe a little heavy-handed, but is there any technical reason not to >just pick an arbitrary FD, like say 3, and just always use that for a >particular daemon? For a given daemon, no, there's no reason not to pick an arbitrary fd and stick to it. That's the intended usage. For a supervisor, the flexibility is a good thing, because daemons may already be using arbitrary fds so it's better not to hardcode anything. -- Laurent ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-07 23:03 ` Brett Neumeier 2020-04-08 11:02 ` Laurent Bercot @ 2020-04-09 10:31 ` Jonathan de Boyne Pollard 1 sibling, 0 replies; 18+ messages in thread From: Jonathan de Boyne Pollard @ 2020-04-09 10:31 UTC (permalink / raw) To: Supervision; +Cc: Supervision Brett Neumeier: > It's maybe a little heavy-handed, but is there any technical reason > not to just pick an arbitrary FD, like say 3, and just always use that > for a particular daemon? Further to what M. Bercot said, see https://unix.stackexchange.com/a/331104/5132 . ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Readiness notification exemplars 2020-04-01 13:23 Readiness notification exemplars Brett Neumeier 2020-04-01 13:36 ` Casper Ti. Vector 2020-04-01 14:21 ` Serge E. Hallyn @ 2020-04-01 14:55 ` Laurent Bercot 2 siblings, 0 replies; 18+ messages in thread From: Laurent Bercot @ 2020-04-01 14:55 UTC (permalink / raw) To: Supervision >I am curious, does anyone on this list know of examples of such daemons? I >am considering creating and submitting patches for some daemon programs >that I use that do *not* support this mechanism as yet, and am curious if >it is as simple as it looks like it should be. - I'm trying to make it so that all my long-lived programs that provide a service support this. For instance, s6-log as Casper mentioned, but also s6-[ipc|tcp]server[d], which are the basic building blocks for simple service implementation. - There is a non-negligible amount of existing daemons in the wild that happen to print a line when they're ready, even though they're not necessarily aware that printing such a line can be used as readiness notification. For instance: * dbus-daemon has the --print-address=fd option that can be used to notify readiness (since the address of the bus is only known after the bus socket is ready). * Xorg has the -displayfd option that can also be used for the same purpose (since it only knows its display once it is ready) * Lots of daemons have an option to print a pidfile. If you run them and give /dev/fd/3 (or whatever your notification-fd is) as a pidfile, they will trigger the notification mechanism when attempting to print their pidfile. Be aware, though, that it does not necessarily mean they're ready; they *should* be, because they should not stamp their pid once they're certain they're going to provide service, but they don't have to, because they know their pid as soon as they're running - and since they're designed badly enough to think a pidfile is a good thing, it's also very possible that they're printing it too early. So you have to check with the daemon's source before using the pidfile option as a readiness check. It is definitely as simple as it looks, it was designed to be able to reuse existing daemon behaviours, and I strongly encourage you to submit patches to spread the use of the mechanism :) -- Laurent ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-04-09 10:31 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-01 13:23 Readiness notification exemplars Brett Neumeier 2020-04-01 13:36 ` Casper Ti. Vector 2020-04-01 14:21 ` Serge E. Hallyn 2020-04-01 15:06 ` Laurent Bercot 2020-04-01 15:28 ` Serge E. Hallyn 2020-04-01 15:59 ` Laurent Bercot 2020-04-01 16:26 ` Serge E. Hallyn 2020-04-01 17:13 ` Laurent Bercot 2020-04-04 15:02 ` Serge E. Hallyn 2020-04-04 15:54 ` Laurent Bercot 2020-04-03 7:41 ` Jonathan de Boyne Pollard 2020-04-04 15:48 ` Serge E. Hallyn 2020-04-04 21:29 ` Laurent Bercot 2020-04-04 22:18 ` Serge E. Hallyn 2020-04-07 23:03 ` Brett Neumeier 2020-04-08 11:02 ` Laurent Bercot 2020-04-09 10:31 ` Jonathan de Boyne Pollard 2020-04-01 14:55 ` Laurent Bercot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).