>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
Received on Wed Apr 01 2020 - 15:06:49 UTC