supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* 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 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

* 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 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-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-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: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-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

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).