Re: Readiness notification exemplars

["Serge E. Hallyn" <serge@hallyn.com>]

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