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

[Lloyd Zusman <ljz@asfast.com>]

prj@po.cwru.edu (Paul Jarc) writes:

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

Yeah ... I meant "the other instance(s) of itself".


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

I was thinking about newer versions.  The apache developers introduced
the "httpd -k stop" syntax in the 2.0.x release for a reason.  I
guessing that they might have done it because they might be planning
more functionality for "stop", "graceful", and "restart" in a future
release ... besides the mere sending of signals to other processes.

But in the current release of apache, these "-k CMD" things are
documented as being equivalent to the sending of signals, so I guess I
shouldn't guess here or plan too far ahead.  That's like coding for the
purpose of maintaining vaporware ... and conjectured vaporware, at
that. :)

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 ... something like this:

  Command="start"
  isstop () {
    Command="stop"
  }
  isrestart () {
    Command="restart"
  }
  isgraceful() {
    Command="graceful"
  }
  trap "isstop"     15
  trap "isrestart"  1
  trap "isgraceful" 30

  case $Command in
  start|restart)
    # do my /tmp cleanup stuff
    ;;
  esac
  # This exec is over-simplified, but you get the idea.
  exec httpd -k $Command -DNO_DETACH

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?


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

Yes.  And upon closer examination, I learned that the authors actually
recommend both of the approaches that are being discussed here: sending
signals or using "httpd -k", which seem for the moment to be equivalent.

I now see that apachectl is not the right way to go in the
runit/daemontools world, and that one of the two other methods should be
used.


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

I forgot about fghack.  Thanks.


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

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.


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

Ah ... yes, that's true.

So given that drawback, how should we solve the problem that I outlined
above?



-- 
 Lloyd Zusman
 ljz@asfast.com
 God bless you.