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:

> Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:
> 
> > On Fri, 25 Jun 2004, Lloyd Zusman wrote:
> >
> > [ ... ]
> >
> >> By "right things" I mean (for apache):
> >> 
> >>   runsvctrl up apache      =>    invoke "apachectl start"
> >>   runsvctrl down apache    =>    invoke "apachectl stop"
> >
> > Why do you say they are the "right things"? Please re-read my previous 
> > message. runsv can already do what "apachectl" does, but more reliably, 
> > and using less resources. Why do you insist on using apachectl?
> 
> See below.

That's an incomplete answer.

> >> I don't want to send a TERM signal to httpd in order to stop it, because
> >> I want it to shut down using the same logic that "apachectl stop" uses,
> >> which is definitely not to simply send a TERM signal to the httpd
> >> daemon.
> >
> > No, that's just what "apachectl stop" does.
> 
> Here's the code fragment within "apachectl" on my system that
> handles the "stop" argument:

Ah, you have a different version of apache to the one I looked at.

> Therefore, an "apachectl stop" causes "httpd -k stop" to be invoked.
> Does passing "-k stop" to httpd cause it to signal itself with
> TERM?

I don't know. strace it, or check the source. I guess that's what it does, 
after finding the right process id, by searching for a pid file. The docs 
suggest I'm right:

http://httpd.apache.org/docs/stopping.html

[Note - the "itself" you use isn't accurate. You pass "-k stop" to a new 
httpd process, not one of the ones which is running. This new process 
tries to pick the parent httpd process from all the ones which are 
running, and sends it a TERM signal.]

> This is Apache 2.0.48, by the way, in case that makes any difference.

It does. I looked at 1.3.x, which uses "kill", not "httpd -k".

> >> [ ... ]
> >
> > Why do you want this extra shell process between runsv and apache, and
> > why do you want to run apachectl?
> 
> Because I want to use the software's own recommended startup and
> shutdown procedures when I invoke it and kill it.

In that case why use runit at all?

I use runit because I want a lightweight, predictable, reliable tool for
managing processes. apachectl, "httpd -k stop" etc are workarounds that
try to fix the problems that runit is designed to avoid.

> It might be that in the specific case of apache, I can safely strip out
> all of the wrapper stuff that its startup script (apachectl) provides,
> but in the general case, I can't always count on this working. 

You need to craft a suitable run script for each service. Unless the 
service that you start mishandles signals when given them, that's probably 
all you need. You need to determine what "suitable" means. Google and a 
cast of hundreds will probably help you there.

> I'd rather rely on startup and shutdown scripts that are supplied with
> the various software packages that I use.  But I want to control them
> via runit mechanisms.

You probably can't do both. And if you can, I doubt it's worth it.

> The amount of extra time that is used to start up and stop a
> long-running daemon like apache by invoking its recommended wrapper
> script inside of "run" is infinitessimal in relation to the daemon's
> lifetime.

So?

If you're like me, you want to use runit to increase the reliability of
your system. That means running as little software as possible. To shut
down apache, you need to give one of the running apache processes (the
right one) a TERM signal. runsv can do that. Why do you want to give a
(putative) bug in apachectl or httpd a chance to be executed?

---
Charlie