Tom Barrett wrote: > > > 2009/12/14 Chris McDonough <[email protected] <mailto:[email protected]>> > > Tom Barrett wrote: > > 2009/12/14 Chris McDonough <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > Please try running supervisor like so: > > supervisord -n -edebug > > This will run it in the foreground with the debug log printing to > stdout, including child process output, which might give you > a clue. > > > How should I simulate the php-cgi process dying? I don't know > what constitues an 'unexpected quit'. A simple 'kill <pid>' > appears to be an 'expected quit'. > > > Nobody could know. I'd just let it run for a while. Note that you > can run supervisord in the background but still log at debug level via: > > supervisord -edebug > > The log message will end up in supervisord.log > > > So there is no way that I can simulate php-cgi going down to see whether > supervisor actually works? Sorry, but that strikes me as borderline > useless. I have, so far, absolutely no evidence that supervisor is any > better than launching programs from the shell and checking them manually. > > How do I poke the beast to make it *do* something? Can I set supervisor > to restart php-cgi no matter why it dies? If not, then I give up.
We're trying to figure out the *circumstance* in which the php process dies so we can teach supervisord to detect it and restart the process *in that circumstance*. Since Supervisor reports an "EXITED" status for this process, it means that the process exited "cleanly" as far as supervisor can tell; it didn't "crash" (at least in Supervisor's eyes). It means the process exited with a status code "cleanly" (the process itself called the UNIX system function "exit()"). Some exit codes are "expected". By default, these are exit status codes 0 and 2. When supervisor sees that a process has exited with an "expected" exit code, by default it does not try to restart the process again. However, if supervisor notices that the exit code is "unexpected" (not in the list of the process' "exitcodes" setting, which by default is 0,2), and "autorestart" is set to "unexpected", it will try to restart the process. It will keep trying to restart the process until "startretries" number of restarts are attempted; if it reaches startretries+1 without a successful startup, it gives up and puts the process into the FATAL status. You can use brute force by setting "autorestart" to "always" in the process configuration, which will make Supervisor always restart the process, by god, no matter what, but it's a heavy hammer, and may have side effects that make it undesirable. It's an option. A better option: By looking at the logs from supervisor when the process "dies" (exits), it will tell you *which* exit code it exited with.. might be 0, might be 2. Dunno. Take this exit code number out of the "exitcodes" list for the process, and it will restart as long as "autorestart=unexpected". And, FTR, indignant proclamations and threats of not using my software aren't great motivators. Cynicism caused by age prevents that from inducing any terror or empathy in me. - C _______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
