On Mon, May 21, 2018 at 05:53:56PM +1000, wirelessduck@??? wrote:
> >> On Tue, 15 May 2018 23:39:24 +1000
> >> Tom <wirelessduck@???> wrote:
> >>
> >>> Thanks as always for your insightful information Steve. Much
> >>> appreciated. As someone who knows very little about init systems,
> >>> can you explain what this respawning business is all about?
> >>
> >> Terminology: I call the init system we've used for 30 years "sysvinit".
> >
> >> I assume here you mean sysvinit when you write sysv-rc.
> >
> > I think Tom is not referring to the whole init system, rather to just the
> > rc scripts:

> Originally, I really had no idea what I was referring to specifically.
> After some more poking around, I think you’re right. I said sysv-rc
> because I noticed that installing the openrc package would only
> uninstall/conflict with the sysv-rc package and not the rest of sysvinit.

The important part is: sane init systems are _modular_. Various fields have
various integration-to-modularity tradeoffs, and init+rc+supervisor schemes
are at such an extreme that I say it would take a deranged mind to argue
that an unextendable blob is fit for this job.

The reason is: none of the contenders is adequate for every single use case,
thus you need to allow the sysadmin to replace pieces with something that
he/she wants. More importantly, "job security" is antithetical to Free
Software: an irreplaceable tangle can't be reasonably improved. A set of
small modules, on the other hand, is _made_ for experiments, many of which
will take over their predecessors. Don't fear change, fear inability to
change.

Main parts here are:

* init. Pid 1. Its tasks are: 1. spawning the rc system; 2. reaping
orphaned processes. That's all. Other functionality might be also
implemented in pid 1, but that's up to you -- for example, sysvinit chose
to add a rudimentary process supervisor whose main use today is spawning
getties -- and a particular contender put pretty much everything there.

* rc system. On De??an started by /etc/init.d/rcS; its tasks are starting
daemons whenever you boot, shutdown, switch to a different runlevel,
install or remove a package, or otherwise manually request. This is
sysv-rc or openrc.

* daemon supervisor. This is what handles daemons that unexpectedly die.
Most daemons are designed to not die, the only case on a regular Unix
system is getty -- anything else tends to be a hallmark of an attack;
usually mindlessly restarting turns a DoS into giving more and more
opportunity of a successful intrusion.

For a real supervisor you want something like runit; sysvinit has inittab
which is extremely limited. OpenRC has no equivalent -- or rather, had
none until the introduction of supervise-daemon which I don't know yet.
But hey, it's not like I'm one of uploaders of openrc or anything to be
supposed to know such things, am I?


.sig related.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄⠀⠀⠀⠀ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall