From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2925 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 14:55:26 +0000 Message-ID: References: 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="99629"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.37929.0 To: Supervision Original-X-From: supervision-return-2514-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Wed Apr 01 16:55:30 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 1jJem9-000PiO-LN for gcsg-supervision@m.gmane-mx.org; Wed, 01 Apr 2020 16:55:29 +0200 Original-Received: (qmail 14129 invoked by uid 89); 1 Apr 2020 14:55:55 -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 14122 invoked from network); 1 Apr 2020 14:55:55 -0000 In-Reply-To: X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrtddvgdektdcutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2925 Archived-At: >I am curious, does anyone on this list know of examples of such daemons? I >am considering creating and submitting patches for some daemon programs >that I use that do *not* support this mechanism as yet, and am curious if >it is as simple as it looks like it should be. - I'm trying to make it so that all my long-lived programs that provide a service support this. For instance, s6-log as Casper mentioned, but also s6-[ipc|tcp]server[d], which are the basic building blocks for simple service implementation. - There is a non-negligible amount of existing daemons in the wild that happen to print a line when they're ready, even though they're not necessarily aware that printing such a line can be used as readiness notification. For instance: * dbus-daemon has the --print-address=3Dfd option that can be used to notify readiness (since the address of the bus is only known after the bus socket is ready). * Xorg has the -displayfd option that can also be used for the same purpose (since it only knows its display once it is ready) * Lots of daemons have an option to print a pidfile. If you run them and give /dev/fd/3 (or whatever your notification-fd is) as a pidfile, they will trigger the notification mechanism when attempting to print their pidfile. Be aware, though, that it does not necessarily mean they're ready; they *should* be, because they should not stamp their pid once they're certain they're going to provide service, but they don't have to, because they know their pid as soon as they're running - and since they're designed badly enough to think a pidfile is a good thing, it's also very possible that they're printing it too early. So you have to check with the daemon's source before using the pidfile option as a readiness check. It is definitely as simple as it looks, it was designed to be able to reuse existing daemon behaviours, and I strongly encourage you to submit patches to spread the use of the mechanism :) -- Laurent