Re: Who actually gets the TERM signal in "runsvctrl down"?

[Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au>]

On Fri, 25 Jun 2004, Lloyd Zusman wrote:

> That's like coding for the purpose of maintaining vaporware ... and
> conjectured vaporware, at that. :)

Now you wouldn't do that, would you?

> However, there's another problem that I need to solve.  In the script
> that I posted in my earlier message, you can see that I do a cleanup of
> certain directories when I do a "start" and a "restart" before actually
> starting the daemon.  But I don't want that cleanup to be done during
> the "graceful" command, which is consistent with its semantics.
> 
> That means that my "run" script would have to tell the difference
> between "restart" and "graceful", and the only way I can see to do this
> in a runit/daemontools environment is to trap the differing signals in
> the script ... 

No.

When you do:

runsvctrl 1 httpd

then the httpd process gets SIGUSR1 (directly) and behaves just as if
you'd typed "httpd -k graceful". Your run script doesn't enter into it -
hopefully it is not running, and has gone away long ago (when it exec'd
httpd).

When you do:

runsvctrl t httpd

then the httpd process gets TERM, and goes through its shutdown process, 
eventually waiting for its children to die, then it exits. Then runsv 
starts up a new instance of your run script, which does the cleanup, then 
execs the new httpd.

> something like this:

No. You're making it complicated. Unnecessarily.

> This situation could occur in any daemon where there are
> installation-specific functions that need to be performed depending on
> whether the daemon is being started, stopped, restarted, etc.
> 
> How can we handle this in the general case?

Being started and being restarted are both covered by what is done in the 
run script. If you need something special done when you stop a daemon 
(which usually is not the case), then with runit you can provide a 
"finish" script.

> > Right - in the general case, we write replacements to make it work. :)
> 
> Yes, we can always write replacements in these cases.  But given the
> situation I described above, the replacements we write for certain
> daemons might have to involve the trapping of the signals that are
> sent by svc/runsvctrl.

Very, very rarely. And not in this case, as far as I've seen.

> > The issue isn't the extra time, it's the inability to send signals
> > reliably.  ("httpd -k stop" almost certainly uses a pid file, which
> > can be out of date.)
> 
> Ah ... yes, that's true.
> 
> So given that drawback, how should we solve the problem that I outlined
> above?

See my various earlier messages. 

All you need to do is create a suitable run script. Perhaps something
like:

#! /bin/sh
exec 2>&1
do_your_cleanup_stuff
TZ=xxxxx exec chpst -P /usr/sbin/httpd -DNO_DETACH

graceful:

runsvctrl 1 httpd ; runsvctrl u httpd

stop:

runsvctrl d httpd

start:

runsvctrl u httpd

restart:

runsvctrl t httpd ; runsvctrl u httpd

Einstein: Things should be made as simple as possible - but no simpler.

---
Charlie