On Tue, 19 May 2020 10:29:02 +0100
Peter Duffy <peter@???> wrote:

> Apologies for following up on my own post - just an afterthought.
>
> When I originally encountered systemd, the word was that it was so
> pervasive that it couldn't be removed (obviously, now we know
> different ;) )
>
> Given the alleged non-optionality of systemd, I started to wonder
> about some kind of an init system wrapper (or even jail) - an
> abstraction layer which would sit between the init subsystem and the
> main system, and sanitise and homogenise interactions between the
> two; init systems, including systemd, could be plugged and unplugged
> into the top surface as desired; the abstraction layer would manage
> commands and responses (including lying to the init subsystem if the
> latter tried to do something dangerous or antisocial).

Oh please don't suggest this: Poettering might do it.

The job of an init system (not systemd, that's a software analogy of
those old electronic circuits encased in epoxy so nobody could reverse
engineer them) is to:

1) Run as PID1, listening for certain

2) PID1 forks off early boot stuff to mount, unencrypt, construct
    devices, set up the network, and the like.

3) PID1 forks off a daemon handler. The best daemon handlers are, in my
    opinion, djb style process supervisors like daemontools, runit and
    s6.

4) Upon receipt of a certain signal, PID1 forks or execs the shutdown
    script.

It really is just that simple. There's no need to add anything to
accommodate badly behaved init system authors.

SteveT

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