From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2495 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Kelly Dean Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 bites noob Date: Sun, 03 Feb 2019 08:53:35 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="125618"; mail-complaints-to="usenet@blaine.gmane.org" Cc: supervision@list.skarnet.org To: Laurent Bercot Original-X-From: supervision-return-2085-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Feb 03 09:54:54 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gqDYD-000WbN-Pu for gcsg-supervision@m.gmane.org; Sun, 03 Feb 2019 09:54:53 +0100 Original-Received: (qmail 16580 invoked by uid 89); 3 Feb 2019 08:55:18 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16573 invoked from network); 3 Feb 2019 08:55:18 -0000 X-Originating-IP: 71.33.65.136 In-reply-to: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2495 Archived-At: Laurent Bercot writes: > It is impossible to portably wait for the appearance of a file. > And testing the existence of the file first, before creating the > subdirs, wouldn't help, because it would be a TOCTOU. s6-supervise aborts on startup if foo/supervise/control is already open, but perpetually retries if foo/run doesn't exist. Both of those problems indicate the user is doing something wrong. Wouldn't it make more sense for both problems to result in the same behavior (either retry or abort, preferably the latter)? https://cr.yp.to/daemontools/supervise.html indicates the original verison of supervise aborts in both cases. I also don't understand the reason for svscan and supervise being different. Supervise's job is to watch one daemon. Svscan's job is to watch a collection of supervise procs. Why not omit supervise, and have svscan directly watch the daemons? Surely this is a common question. I suppose supervise on its own might be convenient during testing, to have a lone supervise proc watching a daemon. But this could be done just as well with a combined svscan-supervise, with the daemon being the only entry in the collection of watched procs. I understand svscan must be as simple as possible, for reliability, because it must not die. But I don't see how combining it with supervise would really make it more complex. It already has supervise's functionality built in (watch a target proc, and restart it when it dies).