On Tue, 19 May 2020 10:29:02 +0100 Peter Duffy <pe...@pwduffy.org.uk> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng