* Who actually gets the TERM signal in "runsvctrl down"? @ 2004-06-25 14:01 Lloyd Zusman 2004-06-25 15:33 ` Charlie Brady 0 siblings, 1 reply; 22+ messages in thread From: Lloyd Zusman @ 2004-06-25 14:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 14:01 Who actually gets the TERM signal in "runsvctrl down"? Lloyd Zusman @ 2004-06-25 15:33 ` Charlie Brady 2004-06-25 16:03 ` Lloyd Zusman 2004-06-25 16:13 ` Dean Hall 0 siblings, 2 replies; 22+ messages in thread From: Charlie Brady @ 2004-06-25 15:33 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 15:33 ` Charlie Brady @ 2004-06-25 16:03 ` Lloyd Zusman 2004-06-25 16:11 ` Charlie Brady 2004-06-25 18:40 ` Jim Zajkowski 2004-06-25 16:13 ` Dean Hall 1 sibling, 2 replies; 22+ messages in thread From: Lloyd Zusman @ 2004-06-25 16:03 UTC (permalink / raw) Cc: Charlie Brady 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 16:03 ` Lloyd Zusman @ 2004-06-25 16:11 ` Charlie Brady 2004-06-25 16:36 ` Lloyd Zusman 2004-06-25 18:40 ` Jim Zajkowski 1 sibling, 1 reply; 22+ messages in thread From: Charlie Brady @ 2004-06-25 16:11 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 16:11 ` Charlie Brady @ 2004-06-25 16:36 ` Lloyd Zusman 2004-06-25 17:15 ` Paul Jarc 2004-06-25 18:27 ` Charlie Brady 0 siblings, 2 replies; 22+ messages in thread From: Lloyd Zusman @ 2004-06-25 16:36 UTC (permalink / raw) Cc: Charlie Brady 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 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-25 18:27 ` Charlie Brady 1 sibling, 2 replies; 22+ messages in thread From: Paul Jarc @ 2004-06-25 17:15 UTC (permalink / raw) Cc: supervision, Charlie Brady 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 17:15 ` Paul Jarc @ 2004-06-26 0:26 ` Scott Gifford 2004-06-26 1:39 ` Lloyd Zusman 1 sibling, 0 replies; 22+ messages in thread From: Scott Gifford @ 2004-06-26 0:26 UTC (permalink / raw) Cc: supervision 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 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 1 sibling, 1 reply; 22+ messages in thread From: Lloyd Zusman @ 2004-06-26 1:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 1:39 ` Lloyd Zusman @ 2004-06-26 2:17 ` Charlie Brady 2004-06-26 2:44 ` Lloyd Zusman 0 siblings, 1 reply; 22+ messages in thread From: Charlie Brady @ 2004-06-26 2:17 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 2:17 ` Charlie Brady @ 2004-06-26 2:44 ` Lloyd Zusman 2004-06-26 3:01 ` Lloyd Zusman 0 siblings, 1 reply; 22+ messages in thread From: Lloyd Zusman @ 2004-06-26 2:44 UTC (permalink / raw) Cc: Charlie Brady 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 2:44 ` Lloyd Zusman @ 2004-06-26 3:01 ` Lloyd Zusman 2004-06-26 4:03 ` Lloyd Zusman 0 siblings, 1 reply; 22+ messages in thread From: Lloyd Zusman @ 2004-06-26 3:01 UTC (permalink / raw) Cc: Charlie Brady 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 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 0 siblings, 2 replies; 22+ messages in thread From: Lloyd Zusman @ 2004-06-26 4:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 4:03 ` Lloyd Zusman @ 2004-06-26 8:17 ` Thomas Schwinge 2004-06-26 15:45 ` Charlie Brady 1 sibling, 0 replies; 22+ messages in thread From: Thomas Schwinge @ 2004-06-26 8:17 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 4:03 ` Lloyd Zusman 2004-06-26 8:17 ` Thomas Schwinge @ 2004-06-26 15:45 ` Charlie Brady 1 sibling, 0 replies; 22+ messages in thread From: Charlie Brady @ 2004-06-26 15:45 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 16:36 ` Lloyd Zusman 2004-06-25 17:15 ` Paul Jarc @ 2004-06-25 18:27 ` Charlie Brady 2004-06-25 19:13 ` Lloyd Zusman 1 sibling, 1 reply; 22+ messages in thread From: Charlie Brady @ 2004-06-25 18:27 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 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 0 siblings, 2 replies; 22+ messages in thread From: Lloyd Zusman @ 2004-06-25 19:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 19:13 ` Lloyd Zusman @ 2004-06-25 19:48 ` Charlie Brady 2004-06-26 3:49 ` Paul Jarc 1 sibling, 0 replies; 22+ messages in thread From: Charlie Brady @ 2004-06-25 19:48 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 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 1 sibling, 1 reply; 22+ messages in thread From: Paul Jarc @ 2004-06-26 3:49 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-26 3:49 ` Paul Jarc @ 2004-06-26 21:10 ` Lloyd Zusman 0 siblings, 0 replies; 22+ messages in thread From: Lloyd Zusman @ 2004-06-26 21:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 16:03 ` Lloyd Zusman 2004-06-25 16:11 ` Charlie Brady @ 2004-06-25 18:40 ` Jim Zajkowski 1 sibling, 0 replies; 22+ messages in thread From: Jim Zajkowski @ 2004-06-25 18:40 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 15:33 ` Charlie Brady 2004-06-25 16:03 ` Lloyd Zusman @ 2004-06-25 16:13 ` Dean Hall 2004-06-25 16:17 ` Charlie Brady 1 sibling, 1 reply; 22+ messages in thread From: Dean Hall @ 2004-06-25 16:13 UTC (permalink / raw) -----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----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: Who actually gets the TERM signal in "runsvctrl down"? 2004-06-25 16:13 ` Dean Hall @ 2004-06-25 16:17 ` Charlie Brady 0 siblings, 0 replies; 22+ messages in thread From: Charlie Brady @ 2004-06-25 16:17 UTC (permalink / raw) Cc: supervision 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 ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-06-26 21:10 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-06-25 14:01 Who actually gets the TERM signal in "runsvctrl down"? 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 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
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).