supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: Supervision <supervision@list.skarnet.org>
Subject: Re: Readiness notification exemplars
Date: Wed, 01 Apr 2020 15:06:49 +0000	[thread overview]
Message-ID: <emf6eb9869-20bf-489b-8608-b0d4c95b36fa@elzian> (raw)
In-Reply-To: <20200401142122.GA30742@mail.hallyn.com>

>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



  reply	other threads:[~2020-04-01 15:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01 13:23 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emf6eb9869-20bf-489b-8608-b0d4c95b36fa@elzian \
    --to=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).