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

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

[Lloyd Zusman]

Who actually receives the TERM signal when "runsvctrl down SVC" is
invoked?  Does that signal get sent to the SVC/run script?

The reason I'm asking is that I'm trying to put apache under runit
control.  I'd like "runsvctrl up apache" to invoke "apachectl start"
(that's trivially easy), and I'd like "runsvctrl down apache" to invoke
"apachectl stop".

If the TERM signal gets sent to the SVC/run script, then I can write a
trap for that signal within that script which would cause
"apachectl stop" to be invoked, thereby providing a clean shutdown.

Or is there a better way to do this?

Thanks in advance.

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

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

[Charlie Brady]

On Fri, 25 Jun 2004, Lloyd Zusman wrote:

> Who actually receives the TERM signal when "runsvctrl down SVC" is
> invoked?  Does that signal get sent to the SVC/run script?

Correct. Or more correctly, the inheritor of that process, presumably an 
apache instance started by exec.

> The reason I'm asking is that I'm trying to put apache under runit
> control.  I'd like "runsvctrl up apache" to invoke "apachectl start"
> (that's trivially easy), and I'd like "runsvctrl down apache" to invoke
> "apachectl stop".
> 
> If the TERM signal gets sent to the SVC/run script, then I can write a
> trap for that signal within that script which would cause
> "apachectl stop" to be invoked, thereby providing a clean shutdown.
> 
> Or is there a better way to do this?

The better way is runit/daemontools. runsvctrl is just a shell script 
which tries to do what runsv is already able to do reliably. It delivers a 
signal to the session leading httpd process, which it has hopefully found 
by way of a pid file. That process then "does the right thing" with its 
children.

For "apachectl stop", just do "runsvctrl down apache". For "apachectl 
graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl 
restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.

---
Charlie

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

[Lloyd Zusman]

Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:

> On Fri, 25 Jun 2004, Lloyd Zusman wrote:
>>
>> [ ... ]
>>
>> The reason I'm asking is that I'm trying to put apache under runit
>> control.  I'd like "runsvctrl up apache" to invoke "apachectl start"
>> (that's trivially easy), and I'd like "runsvctrl down apache" to invoke
>> "apachectl stop".
>> 
>> [ ... ]
>
> The better way is runit/daemontools. runsvctrl is just a shell script 
> which tries to do what runsv is already able to do reliably. It delivers a 
> signal to the session leading httpd process, which it has hopefully found 
> by way of a pid file. That process then "does the right thing" with its 
> children.

Thanks.

I'm already using runit, which I mentioned in my original message (that
paragraph is quoted above).  I understand how runsvctl works in relation
to runit.

I'm trying to figure out how to set up the "run" script in the apache
service directory so that the "down" and "up" parameters to "runsvctrl"
do the right things.

By "right things" I mean (for apache):

  runsvctrl up apache      =>    invoke "apachectl start"
  runsvctrl down apache    =>    invoke "apachectl stop"

[ actually, I already know how to do an "up" ... it's the "down"
  that I have a question about ]

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.

To illustrate, here's an untested, quick and dirty version of the "run"
script in the apache service directory which might do what I want:

  #!/bin/sh

  exec 2>&1

  shutdown () {
    apachectl stop
    exit 0
  }

  trap "shutdown" 15

  apachectl start


I'm just not sure if this is the best way to accomplish what I want
to do.



> For "apachectl stop", just do "runsvctrl down apache". For "apachectl 
> graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl 
> restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.


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

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

[Charlie Brady]

On Fri, 25 Jun 2004, Lloyd Zusman wrote:

> Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:
> 
> >> [ ... ]
> >
> > The better way is runit/daemontools. runsvctrl is just a shell script 
> > which tries to do what runsv is already able to do reliably. It delivers a 
> > signal to the session leading httpd process, which it has hopefully found 
> > by way of a pid file. That process then "does the right thing" with its 
> > children.
> 
> Thanks.
> 
> I'm already using runit, which I mentioned in my original message (that
> paragraph is quoted above).  I understand how runsvctl works in relation
> to runit.
> 
> I'm trying to figure out how to set up the "run" script in the apache
> service directory so that the "down" and "up" parameters to "runsvctrl"
> do the right things.
> 
> 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?

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

> To illustrate, here's an untested, quick and dirty version of the "run"
> script in the apache service directory which might do what I want:
> 
>   #!/bin/sh
> 
>   exec 2>&1
> 
>   shutdown () {
>     apachectl stop
>     exit 0
>   }
> 
>   trap "shutdown" 15
> 
>   apachectl start

Why do you want this extra shell process between runsv and apache, and why 
do you want to run apachectl?

> I'm just not sure if this is the best way to accomplish what I want
> to do.

See below:

> > For "apachectl stop", just do "runsvctrl down apache". For "apachectl 
> > graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl 
> > restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.

You now just need a run script which does:

#! /bin/sh
exec httpd ......

with the correct args.

---
Charlie

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

[Dean Hall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Charlie,

Just some notes and questions for my own edification, somewhat unrelated
to the original post.

Charlie Brady wrote:
| The better way is runit/daemontools. runsvctrl is just a shell script
| which tries to do what runsv is already able to do reliably. It
delivers a
| signal to the session leading httpd process, which it has hopefully found
| by way of a pid file. That process then "does the right thing" with its
| children.

I'm not sure what you mean when you say that runsvctrl does what runsv
already does. As I understand it, it's the Right Thing To Do to send
signals to your service process (or in the case of "u", "d" and "x", to
runsv itself).

(Also, runsvctrl doesn't appear to be a shell script, at least not in
runit-1.0.2.)

| For "apachectl stop", just do "runsvctrl down apache". For "apachectl
| graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl
| restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.

Why are you doing the additional "u"? As I understand it, sending a "u"
to the fifo is really necessary if the service is marked as down. If
after sending any signal to the process it dies/crashes, runsv should
restart it automatically. Does runsv not always do this? (I've never had
any trouble.) If not, sounds like a major bug, as that's what it's
supposed to do.

So when I restart apache, I just do:

runsvctrl t /service/httpd

BTW, I recommend running apache2 with pgrphack so it won't kill other
things when you kill it. Apache 1.3 doesn't seem to have this problem. I
know it has something to do with being the session leader (a la sid()),
but I'm not a Linux systems programmer (nor really a C programmer) and
am not sure what all that entails.


Dean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA3E8fBnn70KGO4CURAuiZAJ400njbPJycCOLp2lNVnJhte5eMyQCggO7u
GZuZ/z8VC1nYlcarfnrZQzA=
=QqIc
-----END PGP SIGNATURE-----

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

[Charlie Brady]

On Fri, 25 Jun 2004, Dean Hall wrote:

> | For "apachectl stop", just do "runsvctrl down apache". For "apachectl
> | graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl
> | restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.
> 
> Why are you doing the additional "u"? As I understand it, sending a "u"
> to the fifo is really necessary if the service is marked as down.

Yes. If the service is down and you do "restart" or "graceful", then to 
preserve the semantics you'll need to up it. The "1" and "t" will be 
effective, and the "u" ignored if the service is already up, the "1" and 
"t" will be NOOPS is the service is down, but "u" will bring it up.

> BTW, I recommend running apache2 with pgrphack so it won't kill other
> things when you kill it.

Is there any reason that runsv shouldn't run each run script as a process
group leader? I've had programs bring down runsv and runsvdir (and
therefore /etc/runit/2). IMO, runsv should protect itself. I can't think
of a downside. Gerrit?

---
Charlie

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

[Lloyd Zusman]

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.


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

  case $ARGV in
  start|stop|restart|graceful)
      $HTTPD -k $ARGV
      ERROR=$?
      ;;
      ... etc. ...
  esac

Therefore, an "apachectl stop" causes "httpd -k stop" to be invoked.
Does passing "-k stop" to httpd cause it to signal itself with
TERM?  If so, can we count on that in all versions of apache?

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


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

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.


> [ ... ]
>
>> > For "apachectl stop", just do "runsvctrl down apache". For "apachectl 
>> > graceful", do "runsvctrl 1 apache; raunsvctrl u apache". For "apachectrl 
>> > restart", do "runsvctrl t apache; raunsvctrl u apache". Etc.
>
> You now just need a run script which does:
>
> #! /bin/sh
> exec httpd ......
>
> with the correct args.

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

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

[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

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

[Charlie Brady]

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

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

[Jim Zajkowski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 25, 2004, at 12:03 PM, Lloyd Zusman wrote:

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

 From httpd (1.3.29) -h:

   -F: run main process in foreground, for process supervisors

 From the httpd manpage:

   To stop it, send a TERM signal to the initial (parent) process.

httpd is designed to run directly under daemontools / runit using the 
- -F parameter to prevent it from detaching and running in the 
background.  What that means: you don't need to, or really should, use 
apachectl.

>   #!/bin/sh
>   [...]
>   apachectl start

Great: apachectl start returns while httpd runs in the background, 
which means daemontools / runit will run your script again, and again.  
You'll need to sleep endlessly.

I run a bunch of webservers all using daemontools control of httpd 
directly.  Works well and is highly reliable.

It seems to me you are missing the fundamental technique that 
daemontools / runit is based around.   This is like trying to use dd as 
a text editor.

- --Jim

- - - -
Jim Zajkowski          OpenPGP 0x21135C3    http://www.jimz.net/pgp.asc
System Administrator  8A9E 1DDF 944D 83C3 AEAB  8F74 8697 A823 2113 5C53
UM Life Sciences Institute

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFA3HGMhpeoIyETXFMRAsyOAKCHh+JpN9k/yBf3tF8n77e/yyu11QCcDlvS
G8YlRWBu17q0JJqjjGmEXLE=
=T214
-----END PGP SIGNATURE-----

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

[Lloyd Zusman]

Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:

> On Fri, 25 Jun 2004, Lloyd Zusman wrote:
>
> [ ... ]
>
>> 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

This one applies to Apache 2:

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

It also documents that the signals will work.  But I want to use the
command line options, in case some future version of apache kills the
daemons in a different way, or perhaps does some cleanup before sending
the signal.


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

Yes, I was imprecise in using the word "itself".  I should have said
this:  "the running instance(s) of itself".


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

Because I want the apache daemon to automatically be restarted in case
it dies.


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

Based on this discussion, I have crafted a run script that is a
compromise between a pure invocation of httpd and the apachectl-based
version that I was previously advocating.  It causes "httpd -k stop",
"httpd -k restart", and "httpd -k graceful" to be invoked when
appropriate signals are received, in case a future version of apache
needs this to be done for cleanup purposes, or whatever.

The script is attached below.


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

You're right.  The normal startup script does not make use of the
-DNO_DETACH option to httpd, which is needed in order for runit to 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.
>
> 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?

For the same reason that I would want to ensure that cleanup is
performed by the daemon before shutdown, which might not occur when a
signal is received.  One might find daemons who don't properly clean up
external resources when a SIGTERM is received; that also is a putative
bug.

For now, I'll take my chances with "httpd -k stop".

De gustibus non disputandum est.


Here's my script, which seems to be working just fine:

#!/bin/sh

exec 2>&1

ApacheHome='/home/services/apache'
ApachePort='80'
HasSSL=1
Command='start'

stopfunc () {
  Command='stop'
}
gracefulfunc () {
  Command='graceful'
}
restartfunc () {
  Command='restart'
}
trap "stopfunc"     15
trap "gracefulfunc" 30
trap "restartfunc"  31

if [ -n "${HasSSL:-}" ]
then
  [ "${Command}" = "start" ] && {
    Command='startssl'
    echo "overriding: start => startssl"
  }
else
  [ "${Command}" = "startssl" ] && {
    Command='start'
    echo "overriding: startssl => start"
  }
fi

echo "invoking $Command"

set -- "${Command}" "$@"

### This stuff is borrowed from the default apachectl script:
#
# The exit codes returned are:
#   XXX this doc is no longer correct now that the interesting
#   XXX functions are handled by httpd
#	0 - operation completed successfully
#	1 - 
#	2 - usage error
#	3 - httpd could not be started
#	4 - httpd could not be stopped
#	5 - httpd could not be started during a restart
#	6 - httpd could not be restarted during a restart
#	7 - httpd could not be restarted during a graceful restart
#	8 - configuration syntax error
#
# When multiple arguments are given, only the error from the _last_
# one is reported.  Run "apachectl help" for usage info
#
ARGV="$@"
#
# |||||||||||||||||||| START CONFIGURATION SECTION  ||||||||||||||||||||
# --------------------                              --------------------
# 
# the path to your httpd binary, including options if necessary
HTTPD="${ApacheHome}/bin/httpd"
#
# pick up any necessary environment variables
if test -f ${ApacheHome}/bin/envvars; then
  . ${ApacheHome}/bin/envvars
fi
#
# Set this variable to a command that increases the maximum
# number of file descriptors allowed per child process. This is
# critical for configurations that use many file descriptors,
# such as mass vhosting, or a multithreaded server.
ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`"
# --------------------                              --------------------
# ||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||
#
### End of stuff that's borrowed from the default apachectl script.

invoke () {
  exec /usr/bin/env -i PATH='/usr/bin:/bin' CHARSET='iso-8859-1' \
       /command/pgrphack $HTTPD "$@"
}

case $ARGV in
start*|restart)

  # Do my own initialization during start or restart.

  # Preprocess the vhosts include file.
  vhostsInc="${ApacheHome}/conf/.vhosts.inc"
  /root/bin/expandVhosts ${ApachePort} >${vhostsInc}
  {
    # Do other initialization
    /bin/rm -rf /tmp/php /tmp/mp
    /bin/mkdir /tmp/php
    /bin/mkdir /tmp/mp
  } 1>/dev/null 2>&1

  # Set the maximum number of file descriptors allowed per child process.
  # (borrowed from default apachectl script)
  if [ "x$ULIMIT_MAX_FILES" != "x" ] ; then
    $ULIMIT_MAX_FILES
  fi
  ;;
esac

case $ARGV in
start|stop|restart|graceful)
    invoke -k $ARGV -DNO_DETACH
    ;;
startssl)
    invoke -k start -DNO_DETACH -DSSL
    ;;
esac

# We should never get here.
exit 2


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

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

[Charlie Brady]

On Fri, 25 Jun 2004, Lloyd Zusman wrote:

> It also documents that the signals will work.  But I want to use the
> command line options, in case some future version of apache kills the
> daemons in a different way, or perhaps does some cleanup before sending
> the signal.

If you try to solve problems you don't already know that people have, you 
create unnecessary complexity. Always start with the simplest possible 
program.
    Russell Nelson

Parts that don't exist can't break.
    Russell Nelson

> > In that case why use runit at all?
> 
> Because I want the apache daemon to automatically be restarted in case
> it dies.

So restart it in the simplest and most reliable way possible.

> For now, I'll take my chances with "httpd -k stop".

You can lead a horse to water ....

---
Charlie

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

[Scott Gifford]

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

[...]

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

There's a patch for Apache (appropriate enough...) that makes it work
with daemontools.  You should be able to find it with Google; if you
can't let me know and I'll dig up my copy.  I've used it on a number
of production sites, and it works fine.

----ScottG.

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

[Lloyd Zusman]

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.

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

[Charlie Brady]

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

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

[Lloyd Zusman]

Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:

> On Fri, 25 Jun 2004, Lloyd Zusman wrote:
>
> [ ... ]
>
> 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.

But look more carefully at the script fragment I wrote in the previous
message: I want to do something different between "restart" and
"graceful" ...

  restart:   before sending the signal to httpd, clean up some
             subdirectories under /tmp that are used in certain web apps
             on my site; and only _then_ send the signal to httpd (do
             this before "start", also, but that's a trivial case)

  graceful:  just send the signal to httpd and _do_ _not_ clean up any
             directories, because in apache, a "graceful" restart keeps
             connections open, etc., and I don't want existing
             data to be lost
             
How do I cause my /tmp directories to get cleaned up during "restart",
but not during "graceful"?


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

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

[Lloyd Zusman]

I just answered my own question.  See below ...


Lloyd Zusman <ljz@asfast.com> writes:

> Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au> writes:
>
>> On Fri, 25 Jun 2004, Lloyd Zusman wrote:
>>
>> [ ... ]
>>
>> 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.
>
> But look more carefully at the script fragment I wrote in the previous
> message: I want to do something different between "restart" and
> "graceful" ...
>
>   restart:   before sending the signal to httpd, clean up some
>              subdirectories under /tmp that are used in certain web apps
>              on my site; and only _then_ send the signal to httpd (do
>              this before "start", also, but that's a trivial case)
>
>   graceful:  just send the signal to httpd and _do_ _not_ clean up any
>              directories, because in apache, a "graceful" restart keeps
>              connections open, etc., and I don't want existing
>              data to be lost
>              
> How do I cause my /tmp directories to get cleaned up during "restart",
> but not during "graceful"?

Hmm ... maybe I can do it this way (almost the same as what you had
suggested, but with a slight difference for "graceful") ...

Use something akin to your suggested "run" script ...

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

Then ...

  start:     runsvctrl u apache
  (causes cleanup stuff to run)

  stop:      runsvctrl d apache
  (no cleanup stuff gets run)

  graceful:  runsvctrl 1 apache
  (no cleanup stuff gets run)

  restart:   runscvtrl t apache; runsvctrl u apache
  (causes cleanup stuff to run during the second command)


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

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

[Paul Jarc]

Lloyd Zusman <ljz@asfast.com> wrote:
> trap "stopfunc"     15
> trap "gracefulfunc" 30
> trap "restartfunc"  31
...
>   exec /usr/bin/env -i PATH='/usr/bin:/bin' CHARSET='iso-8859-1' \
>        /command/pgrphack $HTTPD "$@"

Those signal handlers will never be used, because the shell replaces
itself with httpd.  "start"/"startssl" is the only Command that will
ever be executed.

Your cleanup stuff doesn't have to be in the run script at all.  You
can have a separate script that does that and then calls runsvctrl.


paul

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

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> [ ... ]
>
>   restart:   runscvtrl t apache; runsvctrl u apache
>   (causes cleanup stuff to run during the second command)

We both suggested this one, but I have a question:

Why do we need the second "u" command?  Won't the "run" script restart
on its own after the "t" command, thereby obviating the need for the "u"
command?  In this case, the cleanup stuff in the script will get
re-invoked on restart, correct?


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

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

[Thomas Schwinge]

On Sat, Jun 26, 2004 at 12:03:02AM -0400, Lloyd Zusman wrote:
> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > [ ... ]
> >
> >   restart:   runscvtrl t apache; runsvctrl u apache
> >   (causes cleanup stuff to run during the second command)
> 
> We both suggested this one, but I have a question:
> 
> Why do we need the second "u" command?  Won't the "run" script restart
> on its own after the "t" command, thereby obviating the need for the "u"
> command?

It'll do so if apache was running before.
If it was not running it will just be started.

> In this case, the cleanup stuff in the script will get
> re-invoked on restart, correct?

Yes.


Regards,
 Thomas

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

[Charlie Brady]

On Sat, 26 Jun 2004, Lloyd Zusman wrote:

> Lloyd Zusman <ljz@asfast.com> writes:
> 
> > [ ... ]
> >
> >   restart:   runscvtrl t apache; runsvctrl u apache
> >   (causes cleanup stuff to run during the second command)
> 
> We both suggested this one, but I have a question:
> 
> Why do we need the second "u" command?  Won't the "run" script restart
> on its own after the "t" command, thereby obviating the need for the "u"
> command?  In this case, the cleanup stuff in the script will get
> re-invoked on restart, correct?

Please re-read previous messages (carefully) if something isn't clear. 
This was answered earlier.

To answer your questions - yes to both. But ..

"apachectl restart" will start apache if it is not already running. One of 
the "runsvctrl t" and "runsvctl u" will have no effect during restart - 
but you need to know whether apache is already running to know which one.

The order of "t" and "u" is significant (as is "1" and "u" for 
"graceful"). If you do them in the opposite order, you may hit apache with 
signals during startup, which might result in unexpected behaviour.

---
Charlie

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

[Lloyd Zusman]

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

> Lloyd Zusman <ljz@asfast.com> wrote:
>> trap "stopfunc"     15
>> trap "gracefulfunc" 30
>> trap "restartfunc"  31
> ...
>>   exec /usr/bin/env -i PATH='/usr/bin:/bin' CHARSET='iso-8859-1' \
>>        /command/pgrphack $HTTPD "$@"
>
> Those signal handlers will never be used, because the shell replaces
> itself with httpd.  "start"/"startssl" is the only Command that will
> ever be executed.

Well, that was dumb of me.  Of course.


> Your cleanup stuff doesn't have to be in the run script at all.  You
> can have a separate script that does that and then calls runsvctrl.

As you can see from my subsequent messages here, I've figured out, more
or less, what I need to do, based on what Charlie and you have been so
patiently trying to get across to me.

Thanks to you and to all.


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