On Sat, 14 Jan 2017 18:54:05 -0800
39066dd5_at_gmail.com wrote:
> The s6-svscan behavior fits what I want to do, in this case runit is the
> distro-provided init and so I think it makes sense to patch runsvdir to avoid
> needing to change other parts of the system. It's slightly unfortunate that
> runsvdir isn't designed to be nested so I might do that too while I'm in
> there. I wouldn't expect runit upstream to be all that excited about either
> change though.
>
You mentioned your distro is Void (void).
When I asked on void IRC channel, some time back, void members active there
seemed generally happy with runit and there was not much interest in s6.
But, switching inits on void, is easy, you just change kernel parameter.
Given miniscule size of both runit and s6, it's not a stretch to have both
installed.
So instead of patching runit, have you considered approaching problem other
way around: modifying your void boot sequence to boot into s6?
I believe there is much more "value" to gain that way, than fixing runit's
servicedir runner.
I use void as well, but I am quite unorganized person, so I haven't got very
far in using s6-svscan on void as PID1 yet. For now, I use runit to supervise s6
supervision trees, on personal box, at least.
It seems to me that all that would be needed is wrapping runit's stage1&2
scripts by execline wrappers, to bring machine up and down and to reuse distro
provided scripts at the same time. s6 service tree should be probably separate
from runit one, most runit services should be "copyable" over into s6 though.
But considering you are competent admin, one would expect you are modifying
most runit run scripts anyway.
Of course there might be some hidden gotchas.
Anyway, I guess, that sharing such work, might end up (hopefully) beneficial to
more people in void community, interested in using s6 instead of runit. At
least, I would be interested in being able to use s6-svscan as PID1 on void.
What are you thoughts on this?
eto
Received on Tue Feb 21 2017 - 10:15:05 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC