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

[prj@po.cwru.edu (Paul Jarc)]

Lloyd Zusman <ljz@asfast.com> wrote:
> Does passing "-k stop" to httpd cause it to signal itself with
> TERM?

It signals the other, already-running httpd.

> If so, can we count on that in all versions of apache?

If I were running Apache, I'd try to find a way to make my version
work with daemontools.  I wouldn't worry about older versions, since I
wouldn't be running those.

>> 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.

Right - you want a way that the authors/maintainers say should work.
But you might ask them whether there is such a way other than
apachectl, where you start a program that doesn't put itself into the
background, and which responds to signals like SIGTERM.  If they can
give you such a way, that would be ideal.

If not, then your script should be ok, except that I'd use "fghack
apachectl start" to ensure that the script doesn't exit while Apache
is running.  (Don't use exec, since that would undo the shell's signal
handler.)

> 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.

Right - in the general case, we write replacements to make it work. :)

> 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.

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.)


paul