From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2926 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Readiness notification exemplars Date: Wed, 01 Apr 2020 15:06:49 +0000 Message-ID: References: <20200401142122.GA30742@mail.hallyn.com> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="23765"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.37929.0 To: Supervision Original-X-From: supervision-return-2515-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Wed Apr 01 17:06:51 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 1jJex8-0005xD-3s for gcsg-supervision@m.gmane-mx.org; Wed, 01 Apr 2020 17:06:50 +0200 Original-Received: (qmail 14708 invoked by uid 89); 1 Apr 2020 15:07:16 -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 14701 invoked from network); 1 Apr 2020 15:07:16 -0000 In-Reply-To: <20200401142122.GA30742@mail.hallyn.com> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtddvgdekvdcutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2926 Archived-At: >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=20 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