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:59:25 +0000	[thread overview]
Message-ID: <em6bb5f117-afcd-4289-9b96-69afcab83ea3@elzian> (raw)
In-Reply-To: <20200401152832.GA31205@mail.hallyn.com>

>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



  reply	other threads:[~2020-04-01 15:59 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
2020-04-01 15:28     ` Serge E. Hallyn
2020-04-01 15:59       ` Laurent Bercot [this message]
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=em6bb5f117-afcd-4289-9b96-69afcab83ea3@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).