From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2927 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Serge E. Hallyn" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Readiness notification exemplars Date: Wed, 1 Apr 2020 10:28:32 -0500 Message-ID: <20200401152832.GA31205@mail.hallyn.com> References: <20200401142122.GA30742@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="122345"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Supervision To: Laurent Bercot Original-X-From: supervision-return-2516-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Wed Apr 01 17:28:40 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1jJfIG-000Vgy-MX for gcsg-supervision@m.gmane-mx.org; Wed, 01 Apr 2020 17:28:40 +0200 Original-Received: (qmail 15536 invoked by uid 89); 1 Apr 2020 15:29:05 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 15529 invoked from network); 1 Apr 2020 15:29:04 -0000 Content-Disposition: inline In-Reply-To: Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2927 Archived-At: 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