At
http://skarnet.org/software/s6/why.html
one can find further interesting claims:
> The runit process, not the runsvdir process,
> runs as process 1. This lengthens the supervision chain.
haven't you claimed process #1 should supervise long running
child processes ? runit fulfils exactly this requirement by
supervising the supervisor.
this simplifies both (runit-)init (it has only to compare the PIDs
of terminated child processes with exactly 1 PID) and the
supervisor runsvdir (the latter can do its usual business without
the requirement to do process #1 specific work such as reacting
to signals in a special way, running the 3 different init stages etc.
one could also rightfully point out here that these are proces #1
specific tasks and not a supervisor's duties per se.).
this lengthens the supervision chain but also has the additional
advantage of a supervised supervisor. ;-)
maybe runsvdir was not made to run as process #1 and this was
just a hack its author came up with to replace (SysV) init totally.
who knows ? but it works well (except that runit-init looks at
/etc/runit/reboot etc after receiving SIGCONT which is no good
idea at all since it requires unnecessary read-write access to the
fs this files reside on. how about just reacting to signals, say
use STGTERM to poweroff, SIGHUP to reboot, SIGUSR1 to halt,
SIGUSR2 to reboot or poweroff and make signal handling scripts
like /etc/runit/ctrl-alt-del etc just send one of those signals to
process #1 when SIG(INT,WINCH) were received ?
does not require any read-write fs access and looks much
simpler to me.)
"Artistic considerations":
> runit has only one supervisor, runsv, for both a daemon and its logger.
> The pipe is maintained by runsv. If the runsv process dies, the pipe
> disappears and logs are lost. So, runit does not offer as strong a
> guarantee as daemontools.
sure, if (s6-)svscan dies one is in deep shit aswell, so what is the point
here ? runsv gets restarted by runsvdir but the pipe is gone (are pipes
really closed when the opening (parent) process exits without closing
them itself and subprocesses still use that very pipe ?)
> daemontools' svscan maintains an open pipe between a daemon and its logger,
> so even if the daemon, the logger, and both supervise processes die,
> the pipe is still the same so no logs are lost, ever, unless svscan itself dies.
but:
> perp has only one process, perpd, acting both as a "daemon and logger
> supervisor" (like runsv) and as a "service directory scanner" (like runsvdir).
> It maintains the pipes between the daemons and their respective loggers.
> If perpd dies, everything is lost.
same for (s6-)svscan here (at least for the pipes).
> however, perpd is well-written and has virtually no risk of dying.
the same holds probably for (s6-)svscan, i guess.
> Since perpd cannot be run as process 1,
> this is a possible SPOF for a perp installation
but from a design perspective it seems as reliable as s6-svscan ?
or not since it uses a more integrated desing/approach ?
this design simplifies communication since tasks are not
implemented in other tools running as its (direct) subprocesses.
so all kinds of fifos/pipes used for IPC are not necessary anymore
except one socket per perpd process for client connections
and there is no need for further communication with subprocesses
(except via signals).
Received on Mon Apr 29 2019 - 21:33:47 UTC