supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Kelly Dean <kelly@prtime.org>
To: Laurent Bercot <ska-supervision@skarnet.org>
Cc: supervision@list.skarnet.org
Subject: Re: s6 bites noob
Date: Sun, 03 Feb 2019 08:53:35 +0000	[thread overview]
Message-ID: <bqbqlmzSNJzsTvSRV5wSp6oRvkh4CATkPg6ZWSuBcAL@local> (raw)
In-Reply-To: <em4e294a5f-49fc-4789-b813-54b60b6acd90@elzian>


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).


  parent reply	other threads:[~2019-02-03  8:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 18:32 Kelly Dean
2019-01-31 18:46 ` Kelly Dean
2019-01-31 20:19 ` Laurent Bercot
2019-01-31 21:53   ` svscan --help Jonathan de Boyne Pollard
2019-02-01  0:36   ` s6 bites noob Laurent Bercot
2019-02-01  4:18     ` Kelly Dean
2019-02-01  5:27       ` Colin Booth
2019-02-01  5:29       ` Colin Booth
2019-02-03  8:53   ` Kelly Dean [this message]
2019-02-03 10:19     ` Laurent Bercot
2019-02-04  7:42       ` Kelly Dean
2019-02-04 13:52         ` Laurent Bercot
2019-02-05  9:26           ` Kelly Dean
2019-02-05 19:44             ` Laurent Bercot
2019-02-03 10:39     ` svscan and supervise Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bqbqlmzSNJzsTvSRV5wSp6oRvkh4CATkPg6ZWSuBcAL@local \
    --to=kelly@prtime.org \
    --cc=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).