On Mon, 08 Jul 2019 10:54:58 +0200
Martin Steigerwald <martin@???> wrote:

> Steve Litt - 07.07.19, 01:26:


> > I can't think of anything I or anyone could do, regarding runit
> > runscripts, that would adversely affect sysvinit. As far as systemd,
> > runit and s6 are never going to use the systemd mechanism by which
> > service A tells systemd that it's loaded, but if someone switched
> > back to systemd, that mechanism will still be there.
>
> Why? Currently my package supports both systems with sysvinit as well
> as systemd. There are different debhelper commands for that. I'd
> imagine that would work with runit as well.

Your contention and mine don't contradict: They say the same thing:
There's nothing inherent in runit or s6 that would sabotage one's
moving to sysvinit or systemd for init purposes.

The "systemd mechanism by which service A tells systemd that it's
loaded" I mentioned is sd_notify(), described at:

https://www.freedesktop.org/software/systemd/man/sd_notify.html#

The only thing I was saying is that s6 and runit and sysvinit don't use
sd_notify(), so their methods for detecting the functionality of a
needed prerequisite process or state are different from sd_notify(),
and if one used those methods anywhere but run scripts, they'd need to
be changed out for systemd (or not: They'd actually work for systemd
too).

There's nothing inherent in s6 or runit that would "seal out" other
inits. In fact, I'm a big proponent of having all the inits installed
at the same time, so if you need to switch inits, short term you edit
grub, long term you rename the PID1 executable. I've had cases where I
borked an init system, and I was darn glad I had a second, working init
system to boot to.

SteveT

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