On Thu, 11 Oct 2018 23:23:38 -0700
Rick Moen <rick@???> wrote:

> Part
> of the point I wanted to make, here (bearing in mind that I'm
> speaking only my own view), is that Devuan needs to be mindful of
> priorities and has necessarily limited volunteer effort. For better
> or worse, _if_ I understand correctly, for now Devuan's primary
> delivery target for current and future releases involves SysVInit.
>
> As it hapens, I personally share your liking for OpenRC over SysVInit,
> and respect runit based on readings but haven't experimented with it
> as Steve Litt has. But my point is that, if I guess correctly, in the
> short term there may not be enough time/effort available to build in
> fully packaged, optimally architected implementations of those two
> init systems.

Speaking for both runit and s6, packaging isn't all that necessary. A
document would suffice. Runit's not a huge monster like sysvinit (or
a massively entangled monolith like systemd). And in my opinion, the
capability of initting with multiple inits is s *good* thing.

>
> The other immediate thought I had, and I'll just throw this out as a
> slightly rhetorical question: Is it so bad to retain the PID1-process
> fragment of SysVinit, e.g., as what runs the OpenRC init system?
> Seems to me, it's the part of SysVinit nobody has any significant
> problem with. It's not unreasonably complex, it's not notably buggy,
> and it's certainly not overfeatured.

Yes. First of all, you need sysvinit or something like it to be
OpenRC's PID1, so yeah, install sysvinit just to init via OpenRC:
That's how OpenRC is designed to be used, and /etc/inittab is OpenRC's
way of doing respawns (unless OpenRC has recently acquired powers I
don't know about). Second, it's quite a bit easier to run runit as a
non-init supervisor, using sysvinit's PID1. All you do when you want
sane supervision is:

1) Permanently disable the service from /etc/rc.d/init.d

2) Obtain a runit run script (from Void Linux?)

3) Spin up the service in runit: Mainly just install a symlink.

The three preceding work equally well for s6, although I know of no
distro defaulting to s6 so somebody has to write the run scripts. None
of what we're talking about involves changes to current packaging, so
we can respect the priorities Rick discussed.

>
> I note with interest and appreciation your suggestions about how runit
> might be provided in better built packaging, but will leave it to
> others (such as my friend Steve Litt) to comment. Daniel's wording
> about a way to extend these ideals into a framework for other init
> systems is particularly cheering, so thanks for posting that.

My understanding is that the current Debian runit package is sufficient
to use runit as a non-initting, non-PID1 *supervisor*. If this is true,
why not run it (no pun intended) that way? We'd need a document stating
best practices in turning off the daemon from /etc/rc.d/init.d, and
we'd need to grab the run script from Void and make sure it works.

Everyone knows I don't like sysvinit, because of the monstrous init
scripts. But if supervision is done by runit, s6 or daemontools-encore,
my entire objection goes away, because the sysvinit scripts aren't
used. There's nothing wrong with the PID1 part of sysvinit.

SteveT

Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz