supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Lloyd Zusman <ljz@asfast.com>
Cc: Charlie Brady <charlieb-smarden-supervision@budge.apana.org.au>
Subject: Re: Who actually gets the TERM signal in "runsvctrl down"?
Date: Fri, 25 Jun 2004 12:36:50 -0400	[thread overview]
Message-ID: <m3acyrh9wd.fsf@asfast.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0406251205560.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:
>
> [ ... ]
>
>> 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.



  reply	other threads:[~2004-06-25 16:36 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 [this message]
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
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=m3acyrh9wd.fsf@asfast.com \
    --to=ljz@asfast.com \
    --cc=charlieb-smarden-supervision@budge.apana.org.au \
    /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).