Re: Readiness notification exemplars

From: Serge E. Hallyn <serge_at_hallyn.com>
Date: Wed, 1 Apr 2020 11:26:00 -0500

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
Received on Wed Apr 01 2020 - 16:26:00 UTC