On Thu, 21 May 2020 10:59:15 +0100
Peter Duffy <peter@???> wrote:

> I think that the thing that I found tantalising was the idea of
> sniffing what systemd tried to do, and then deciding whether or not
> to do it,

Many have tried this. Web search "uselessd".

But your suggestion becomes much more valuable if expressed as
"sniffing what each init system tried to do, and then deciding whether
or not to do it".

* Busybox init
* Epoch
* OpenRC
* Runit
* s6 (plus s6-rc)
* Suckess init plus [daemontools | runit | s6]
* systemd
* sysvinit

> and what responses to send back to systemd.

If you mean the daemon reports back to the process supervisor success
or failure, s6 has that now, in a much simpler form than systemd's
dbus-centered bizarro. And such reporting isn't all that necessary
because the admin can roll his own tests.

If you mean do this research and report the research results back to
the systemd project, I'm not interested in helping systemd, and systemd
isn't interested in anything making them more interoperative.

SteveT

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