On Sat, 14 May 2016 18:26:17 +0000
hellekin <hellekin@???> wrote:

> On 05/03/2016 06:10 PM, Steve Litt wrote:
> >
> > IMHO the package should install [every init]
> >
>
> Some time ago I suggested an init-freedom package for that purpose,
> that would provide init, and require at least one of the init systems
> to be installed, like, e.g., mail-transport-agent does. Then it
> would propose you to "use N at next boot" or something useful like
> that, only for init systems ready to use (i.e., you need to configure
> them properly first)
>
> The prospects sounds interesting but usually one would use one init
> system per physical host, and testing can be done with virtual
> machines. When test on real hardware becomes necessary, having this
> might help.

I don't remember the exact context of the discussion, but I always
recommend that installing a given init doesn't remove the others. Even
on a production machine, if for *some reason* the init suddenly fails,
it's nice to be able to use another init. And, as you mention, when
experimenting on a VM, init switching is a regular part of the
scientific method.

>
> Using the alternatives system such program might be even simple to
> implement.
>
> More generally I'd like to consider "init" as a set of components you
> can combine to form "the init process":
>
> - boot

What is boot? Is that the stuff in the hardware's permanent memory?
Does it include the initramfs?


> - PID1 (init proper)
> - process management
> - device management

What is device management? Is that the stuff udev and vdev and eudev
usually do?

> Each component can be covered by one or more programs (e.g., systemd
> does all these an more, openrc can do PID1 and process management,

OpenRC can't do PID1. It needs sysvinit, Busybox, Suckless Init, or
some other PID1, to pass control to it. It has no PID1 capability at
all.

In reality, this lack of PID1 is no problem: There are plenty of PID1s
to stand in. The only problem is that OpenRC can't respawn, which means
it needs something else to run gettys (virtual terminals). Sysvinit
works perfectly in this role because it can respawn the gettys early in
the init. If you used Suckless Init, you'd need to run a respawning
process manager on top of OpenRC in order to get your gettys, and this
prevents an early getty (for when boot stops early and you have to
investigate).

You could probably run daemontools-encore (via svscanboot) early in the
first rc file to get your early gettys.

SteveT

Steve Litt
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21