On Mon, 18 Jul 2016 19:12:37 +0200
<emninger@???> wrote:

> Hi!
>
> On the road to a viable jwm desktop in devuan, i am using/trying
> open-rc. In advance, my excuses if what follows is not sufficiently
> technical.
>
> To the point: From Manjaro-OpenRC i knew openrc as a clean and logical
> system to manage daemons & processes. By far, from a user point of
> view, superior to sysvinit. Now, the transition from sysvinit to
> openrc in devuan is mostly painless. BUT: I'm under the impression in
> devuan/debian openrc works only as a kind of wrapper around sysvinit.

The "wrapper around sysvinit" thing is a feature of OpenRC, not
Devuan/Debian's implementation thereof. A little more explanation...

What's commonly called an "init system" can be thought of as two
separate components:

1) PID1, the first program the kernel runs. PID1 does two things: fork
off an init script, and circle around listening for signals.

2) Process manager. This runs the necessary background programs, and
if it's about its business, enables you to interact with them and
maybe even respawn them if they crash. The process manager is, or is
run by, the rc file forked off by PID1.

The preceding two component model is more conceptual than real.
Although it perfectly describes the runit init system, it's not how s6
works, and it's completely different from systemd, which of course
isn't an init system at all but only contains one. I have no idea how
sysvinit is built internally.

The two component model is at least conceptually descriptive of
sysvinit. It has a PID1 which forks off an rc file that calls all the
stuff in /etc/rc.d/rc5.d or whatever. The stuff named in /etc/inittab
is respawnable, and I don't know whether it exists in PID1 or is passed
to the rc file.

OpenRC has only one component: The process manager. It has no PID1. The
easiest way to team it up with a PID1 is to use sysvinit as PID1,
because then you can start up respawnables from /etc/inittab. But you
can also PID1 OpenRC from Suckless Init, Felker Init, and who knows,
maybe even runit's PID1.

So, OpenRC needs a PID1, sysvinit is by far its most used PID1, which
is why OpenRC might seem like a wrapper around sysvinit. And, as I
said, this is a property of OpenRC itself, not any distro's
implementation. Like you said, init scripts might be laid out totally
differently in different distros,but OpenRC distros all require a
separate PID1 (and almost always use sysvinit), because OpenRC has no
PID1 of its own.

I'm not an OpenRC fan. It appears not to be able to respawn (although
there's some question about this), its init scripts appear to be just
as huge and confusing as those of sysvinit, and its init scripts are
written in a language slightly different from /bin/bash or /bin/sh. My
view: If I'm going to take the trouble to replace sysvinit, I want
something substantially different: runit, Epoch, and maybe s6 or s6-rc
come to mind. runit and Epoch have amazingly tiny and simple run
scripts and process configs, respectively. Runit always respawns its
later processes, and Epoch gives you the choice to respawn any process
it runs. Epoch and runit have such simple process configs and run
scripts that a mere user can modify, troubleshooter or create them.


SteveT

Steve Litt 
July 2016 featured book: Troubleshooting Techniques
     of the Successful Technologist
http://www.troubleshooters.com/techniques