The runsv executable is pretty robust, so it's unlikely to die.
Yadda yadda yadda. Most daemons are also unlikely to die, so following
your reasoning, I wonder why we're doing supervision in the first place.
Hint: we're doing supervision because we are not content with
"unlikely". We want "impossible".
as somebody killing it accidentally or on purpose with the kill
command, that's a marginal case. But if it were *really* important to
protect against, fine, have one link dir per early longrun, and run an
individual runsvdir on each of those link directories.
And you just increased the length of the chain while adding no
guarantee at all, because now someone can just kill that runsvdir first
and then go down the chain, like an assassin starting with the
bodyguards of the bodyguards of the important people. Or the assassin
might just use a bomb and blow up the whole house in one go: kill -9 -1.
The main point of supervision is to provide an absolute guarantee
that some process tree will always be up, no matter what gets killed
in what order, and even if everything is killed at the same time. You
can only achieve that guarantee by rooting your supervision tree in
With runit, only the main runsvdir is supervised - and even then it
isn't really, because when it dies runit switches to stage 3 and reboots
the machine. Which is probably acceptable behaviour, but still not
supervision. And everything running outside of that main runsvdir is
just hanging up in the air - they can be easily killed and will not
By adding supervisors to supervisors, you are making probabilistic
statements, and hoping that nobody will kill all the processes in the
wrong order. But hope is not a strategy. There is, however, a strategy
that works 100% of the time, and that is also more lightweight because
it doesn't require long supervisor chains: rooting the supervision tree
in process 1. That is what an s6-based init does, and it provides real,
strong supervision; and unlike with runit, the machine is only rebooted
when the admin explicitly decides so.
If you're not convinced: *even systemd* does better than your solution.
systemd obviously has numerous other problems, but it does the
"root the supervision tree in process 1" thing right.
I appreciate your enthusiasm for supervision suites. I would appreciate
it more if you didn't stop halfway from understanding everything they
bring, and if you didn't paint your unwillingness to learn more as a
technical argument, which it definitely is not, while flippantly
dismissing contributions from people who know what they are talking