On Mon, 08 Jul 2019 10:54:58 +0200 Martin Steigerwald <mar...@lichtvoll.de> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
