From: Guillermo <gdiazhartusch@gmail.com>
To: supervision <supervision@list.skarnet.org>
Subject: Re: further claims
Date: Wed, 1 May 2019 20:09:58 -0300 [thread overview]
Message-ID: <CADQ2Nw_3hGEhFtY1cQptDL3LQJOPNyNQ0ax8zEF=PTi1PDcmmA@mail.gmail.com> (raw)
In-Reply-To: <em33d79abe-979e-471b-b7a7-63b8d895a8fa@elzian>
El mar., 30 abr. 2019 a las 5:55, Laurent Bercot escribió:
>
> >haven't you claimed process #1 should supervise long running
> >child processes ? runit fulfils exactly this requirement by
> >supervising the supervisor.
>
> Not exactly, no.
> If something kills runsvdir, then runit immediately enters
> stage 3, and reboots the system. This is an acceptable response
> to the scanner dying, but is not the same thing as supervising
> it. If runsvdir's death is accidental, the system goes through
> an unnecessary reboot.
If the /etc/runit/2 process exits with code 111 or gets killed by a
signal, the runit program is actually supposed to respawn it,
according to its man page. I believe this counts as supervising at
least one process, so it would put runit in the "correct init" camp :)
There is code that checks the 'wstat' value returned by a
wait_nohang(&wstat) call that reaps the /etc/runit/2 process, however,
it is executed only if wait_exitcode(wstat) != 0. On my computer,
wait_exitcode() returns 0 if its argument is the wstat of a process
killed by a signal, so runit indeed spawns /etc/runit/3 instead of
respawning /etc/runit/2 when, for example, I point a gun at runsvdir
on purpose and use a kill -int command specifying its PID. Changing
the condition to wait_crashed(wstat) || (wait_exitcode(wstat) != 0)
makes things work as intended.
G.
next prev parent reply other threads:[~2019-05-01 23:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 21:33 Jeff
2019-04-30 8:56 ` Laurent Bercot
2019-05-01 23:09 ` Guillermo [this message]
2019-05-02 0:30 ` Colin Booth
2019-05-03 2:44 ` ToyBox oneit Jeff
2019-05-05 2:07 ` ToyBox init Jeff
2019-05-03 2:15 ` Runit Jeff
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='CADQ2Nw_3hGEhFtY1cQptDL3LQJOPNyNQ0ax8zEF=PTi1PDcmmA@mail.gmail.com' \
--to=gdiazhartusch@gmail.com \
--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).