From: Lloyd Zusman <ljz@asfast.com>
Subject: Re: Who actually gets the TERM signal in "runsvctrl down"?
Date: Fri, 25 Jun 2004 15:13:09 -0400 [thread overview]
Message-ID: <m3eko3e9iy.fsf@asfast.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0406251405580.11857-100000@e-smith.charlieb.ott.istop.com>
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.
next prev parent reply other threads:[~2004-06-25 19:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-25 14:01 Lloyd Zusman
2004-06-25 15:33 ` Charlie Brady
2004-06-25 16:03 ` Lloyd Zusman
2004-06-25 16:11 ` Charlie Brady
2004-06-25 16:36 ` Lloyd Zusman
2004-06-25 17:15 ` Paul Jarc
2004-06-26 0:26 ` Scott Gifford
2004-06-26 1:39 ` Lloyd Zusman
2004-06-26 2:17 ` Charlie Brady
2004-06-26 2:44 ` Lloyd Zusman
2004-06-26 3:01 ` Lloyd Zusman
2004-06-26 4:03 ` Lloyd Zusman
2004-06-26 8:17 ` Thomas Schwinge
2004-06-26 15:45 ` Charlie Brady
2004-06-25 18:27 ` Charlie Brady
2004-06-25 19:13 ` Lloyd Zusman [this message]
2004-06-25 19:48 ` Charlie Brady
2004-06-26 3:49 ` Paul Jarc
2004-06-26 21:10 ` Lloyd Zusman
2004-06-25 18:40 ` Jim Zajkowski
2004-06-25 16:13 ` Dean Hall
2004-06-25 16:17 ` Charlie Brady
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3eko3e9iy.fsf@asfast.com \
--to=ljz@asfast.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).