:: [DNG] Systemd sd_notify(): was Runi…
Top Page
Delete this message
Reply to this message
Author: Steve Litt
To: dng
Old-Topics: Re: [DNG] Runit service depend another script not daemon
Subject: [DNG] Systemd sd_notify(): was Runit service depend another script not daemon
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:


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

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.


Steve Litt 
July 2019 featured book: Troubleshooting Techniques
     of the Successful Technologist