From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/489 Path: main.gmane.org!not-for-mail From: Lloyd Zusman Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Who actually gets the TERM signal in "runsvctrl down"? Date: Fri, 25 Jun 2004 21:39:12 -0400 Sender: news Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1088214060 31489 80.91.224.253 (26 Jun 2004 01:41:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 Jun 2004 01:41:00 +0000 (UTC) Original-X-From: supervision-return-727-gcsg-supervision=m.gmane.org@list.skarnet.org Sat Jun 26 03:40:50 2004 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1Be2BW-0001RG-00 for ; Sat, 26 Jun 2004 03:40:50 +0200 Original-Received: (qmail 17869 invoked by uid 76); 26 Jun 2004 01:41:10 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 17863 invoked from network); 26 Jun 2004 01:41:09 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-To: supervision@list.skarnet.org Original-Lines: 128 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: hippo.asfast.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:zTIuH3va2poQp6PRSZ1QWpOb8Aw= Xref: main.gmane.org gmane.comp.sysutils.supervision.general:489 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:489 prj@po.cwru.edu (Paul Jarc) writes: > Lloyd Zusman 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.