From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2621 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: killall test run Date: Sun, 19 May 2019 17:39:37 -0300 Message-ID: References: <11997211556565598@myt6-27270b78ac4f.qloud-c.yandex.net> <20190501033355.6e41e707@mydesk.domain.cxm> <20190515132206.03f9736e@mydesk.domain.cxm> <20190516012214.15ffcf2e@dickeberta> <20190515210717.27b002ba@mydesk.domain.cxm> <5f5b6035-240b-e6d6-497d-d9bb945d135f@obarun.org> <5994381558140755@sas2-2074c606c35d.qloud-c.yandex.net> <57af526d-cc12-135b-218c-721d51129876@obarun.org> <9538981558270634@myt3-c573aa6fc782.qloud-c.yandex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="46592"; mail-complaints-to="usenet@blaine.gmane.org" To: super Original-X-From: supervision-return-2211-gcsg-supervision=m.gmane.org@list.skarnet.org Sun May 19 22:39:49 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 1hSSaz-000C3N-FZ for gcsg-supervision@m.gmane.org; Sun, 19 May 2019 22:39:49 +0200 Original-Received: (qmail 22203 invoked by uid 89); 19 May 2019 20:40:15 -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 22195 invoked from network); 19 May 2019 20:40:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=dHPSoof908onzr57t8UHja+EDHG4kMWJzciQcw1E/Fk=; b=sKVMXLCcEJmPeyrlHNLqxaMVq6Sj9RgK6tmcoWhNBywmRV6s74pYlME2SDIeupCDm1 jD5tq7zPrrtbNlLLJfBFvJ0kJ2MqL00xje3BGOiPpVSwl03bUTalHFC40vTJ/mwkwXqU xTFb9dIr5NpynOSGE2A6ZYP11eeoqGyR0n16xd6z+qTTm7nJmMl/AV2En2GRe+oro6bG FEjs8LQZvUC7mIggRfJfifPEEGjom4UoM9HNwoOCt0gIzX57dNIQbJakV8SHWAu25Kpa EeHIOH8N9o/KGV7VH/OLYwgemLFdg3rYr+MR/FORjW5/MUO6KhH6YX+OrCnklaw1tyCj Ay+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=dHPSoof908onzr57t8UHja+EDHG4kMWJzciQcw1E/Fk=; b=C1VVKLmoGFKQNzezxbO4iu5gVP2qx4gtH11IFplSqWdjjYXN4pG/uGAc/l2NIfB7ei CnmoaXV9r1LDIPNGnAaMbl72rIe4IjQ0fhzi++4bs7nJUC7JIDyhUxm7yOroP4Dgdjo9 X8PWRliXxHFHTJLqX54ti4+p76gNP6wb8O2UrXYSWJjQNIhg0bKoGs3iMmi+AUFTqKZp umiaMMF/wTBuCHO1g41Rvq6oTKgJoXk9ZqKZKZxV8Wn6PtVE3v58yIRPhZzn/2lcDKsl wtvsWma66+cs/jNVVDFAm46iP8P7KLtKdD2vVXLsyy8bvSPURu8AX6nO1tMEbjP+gwYJ 6MkQ== X-Gm-Message-State: APjAAAW3+J2PrXchRJC5Ej0fKFDoisi9/CQaZZrAq1FbINaRAbndOFMR x2u3J1UMyi1LRGZ7Oeq23toI3/Je8KTVn/OpPIxZKw== X-Google-Smtp-Source: APXvYqzhOkzPlt0p5jc3/4ZxrhdJK6c8gEXPUjF6v6NypKeFv1nk5XrShn3pr3Hq0uQ5YOjsTAjxx2A6smRLSLl84u0= X-Received: by 2002:a05:660c:4c2:: with SMTP id v2mr27133402itk.71.1558298387304; Sun, 19 May 2019 13:39:47 -0700 (PDT) In-Reply-To: <9538981558270634@myt3-c573aa6fc782.qloud-c.yandex.net> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2621 Archived-At: El dom., 19 may. 2019 a las 9:57, Jeff escribi=C3=B3: > > OpenRC is known to work with s6-svscan (this is done via the > /libexec/rc/sh/s6.sh shell script). That is part of OpenRC's s6 integration feature, and, although on the surface it looks like a nice thing to have, the implementation of it launches s6-svscan with start-stop-daemon, which means that: * s6-svscan is not supervised. * s6-svscan's standard output and error are redirected to /dev/null, so logs from services that don't have a corresponding logger go to the trash can. Or at least it was like that last time I checked. > although it is better to start > s6-svscan from /etc/inittab (directly or - as i prefer - via a starter > shell/execline script that ensures at least the scandir exists) > since SysV init can respawn processes anyway (supervised > supervisor ;-). That seems to be the route that Ad=C3=A9lie has taken. With an execline script, /lib/s6/s6-svscanboot, configured in an /etc/inittab 'respawn' entry. This results in a supervised s6-svscan (by sysvinit), and a supervised catch-all logger. > i do not know the order > in which sysvinit processes the inittab entries for a given (SysV) > "runlevel". do "wait" entries precede "respawn" entries, followed > by the "once" entries ? I believe they are processed in line order. G.