danhunsaker
commented
11 years ago kill -9 will always work, but by definition it never allows an application to properly clean up after itself. I would personally recommend against it whenever possible.
That said, the scheduler itself doesn't intercept any signals, so PHP should be handling that automatically. When you start php-resque-scheduler, are you starting it in an environment with the PIDFILE variable set to /var/run/resque/scheduler-worker.pid? The easiest way to ensure this, of course, is to include it as part of the start command in your monit config: PIDFILE="/var/run/resque/scheduler-worker.pid" /path/to/php-resque-scheduler. Without that variable in the environment, the PID file never gets created, and your kill command never gets a valid PID on its command line. In fact, kill probably complains about this, but the exit 0 portion of the stop program line prevents this complaint from reaching you, except perhaps in a log file someplace.
If the script is starting in an environment that does have this variable set (you could modify bin/resque-scheduler to report the contents of this variable on start in order to verify that this is the case), then the issue lies elsewhere, and we'll probably need more details to help figure out what's up. My initial reaction, though, is that PIDFILE isn't making it all the way through to the startup script.
chuanma
We use the exact stop command provided with php-resque-scheduler:
We found that the pid file was removed, but the scheduler worker wasn't killed. What would be the root cause of that? Could we use
kill -9ifkill -s QUITdoesn't work?