Re: [DNG] Switching to OpenRC, including respawn

[Steve Litt]

On Mon, 21 May 2018 19:05:37 +1000
wirelessd...@gmail.com wrote:

> > On 14 May 2018, at 18:51, Steve Litt 
> > wrote:
> > 
> > One property of OpenRC is it has no facility to respawn a daemon
> > when the old daemon crashes. Some folks like it this way, some
> > don't, but it's a fact of OpenRC. Except...
> > 
> > There are two ways to have OpenRC respawn. Way 1 is to run the
> > daemon from /etc/inittab, with the "respawn" flag. Remember, OpenRC
> > doesn't have its own PID1, and traditionally uses sysvinit's PID1.
> > 
> > Way 2 is to have OpenRC run either runit or s6 from /etc/inittab
> > with "respawn", and then to put all respawnable daemons in runit or
> > s6. Running either runit or s6 *as a supervisor rather than an
> > init* is dead-bang easy. Since about 2010 I've been doing something
> > similar: I ran daemontools on top of sysvinit, and it always worked
> > out great for me.
> > 
> > SteveT  
> 
> I had a closer look at OpenRC docs and noticed they now include a
> built-in “supervise-daemon”[1] supervisor that can be used instead of
> the default start-stop-daemon.  It will restart a daemon if it
> terminates unexpectedly.

Dang that's big news, and changes things profoundly. From reading it,
did it look like you could use the start-stop on some things,  and the
"supervise daemon" on others? That would be ideal.

> 
> The only issue with it for my use case is that I couldn’t find any
> way to send an arbitrary signal to the supervised daemon without
> signalling it to stop. The problem being that the pidfile created
> exists for the individual supervisor process and not the supervised
> daemon process.

I'll tell you about signals in runit, in the hope that you can find
something similar in OpenRC. Runit has the sv command, which can be
used to start the process being supervised, send signals to the process,
or get info about the process:

sv down sshd sends TERM then CONT to sshd

Without going into syntax, sv can easily send any of the following
signals to the daemon (sshd in this example):

STOP, CONT, HUP, ALRM, INT, QUIT, USR1, USR2, TERM, or KILL

But wait, there's more. If somehow you need to send yet some other
signal, the generic way is to find the daemon's PID is the following:


[root@mydesk ~]# sv status sshd
run: sshd: (pid 739) 56174s
[root@mydesk ~]#


A little awk-foo, and you have your PID, and from there, you can use
the kill command (or equivalent in whatever language you're using) to
send absolutely any signal to that PID.

I bet OpenRC's supervisor has an equivalent to sv status, because
daemontools, runit and s6, all prior art, have that capability.

SteveT

Steve Litt 
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Switching to OpenRC, including respawn

[wirelessduck]

> On 14 May 2018, at 18:51, Steve Litt  wrote:
> 
> One property of OpenRC is it has no facility to respawn a daemon when
> the old daemon crashes. Some folks like it this way, some don't, but
> it's a fact of OpenRC. Except...
> 
> There are two ways to have OpenRC respawn. Way 1 is to run the daemon
> from /etc/inittab, with the "respawn" flag. Remember, OpenRC doesn't
> have its own PID1, and traditionally uses sysvinit's PID1.
> 
> Way 2 is to have OpenRC run either runit or s6 from /etc/inittab with
> "respawn", and then to put all respawnable daemons in runit or s6.
> Running either runit or s6 *as a supervisor rather than an init* is
> dead-bang easy. Since about 2010 I've been doing something similar: I
> ran daemontools on top of sysvinit, and it always worked out great for
> me.
> 
> SteveT

I had a closer look at OpenRC docs and noticed they now include a built-in 
“supervise-daemon”[1] supervisor that can be used instead of the default 
start-stop-daemon.  It will restart a daemon if it terminates unexpectedly.

The only issue with it for my use case is that I couldn’t find any way to send 
an arbitrary signal to the supervised daemon without signalling it to stop. The 
problem being that the pidfile created exists for the individual supervisor 
process and not the supervised daemon process.

[1] https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md

—Tom___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Switching to OpenRC, including respawn

[Steve Litt]

One property of OpenRC is it has no facility to respawn a daemon when
the old daemon crashes. Some folks like it this way, some don't, but
it's a fact of OpenRC. Except...

There are two ways to have OpenRC respawn. Way 1 is to run the daemon
from /etc/inittab, with the "respawn" flag. Remember, OpenRC doesn't
have its own PID1, and traditionally uses sysvinit's PID1.

Way 2 is to have OpenRC run either runit or s6 from /etc/inittab with
"respawn", and then to put all respawnable daemons in runit or s6.
Running either runit or s6 *as a supervisor rather than an init* is
dead-bang easy. Since about 2010 I've been doing something similar: I
ran daemontools on top of sysvinit, and it always worked out great for
me.

SteveT


On Mon, 14 May 2018 02:33:21 -0400
chill...@protonmail.com wrote:

> Afaik openrc is compatible with the init scripts used by all
> packages. Installing it and rebooting should be enough to start using
> openrc. It worked OK for me when I tested it.
> 
> This is probably possible on Jessie as well but I haven't tested that.
> 
> ​Cheers,
> 
> chillfan
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On May 14, 2018 1:52 AM,  wrote:
> 
> > I’ve read that the ascii RC has optional support for OpenRC. How
> > can I switch to this on an existing system to try it out?
> > 
> > Is it simply a matter of running “apt-get install openrc”?
> > 
> > If I switch, will I have to create new service definition files for
> > each existing daemon in /etc/init.d or can it read and reuse those
> > files automatically?
> > 
> > Are there any good tutorials out there on using it, aside from the
> > Gentoo documentation?
> > 
> > Thanks
> > 
> > —Tom
> > 
> > Dng mailing list
> > 
> > Dng@lists.dyne.org
> > 
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng  
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng