How to stop delayed_job if I run it with the -m "monitor" parameter?

Question

How to stop delayed_job if I run it with the -m "monitor" parameter? Processes continue to reboot!

The command with which I run delayed_job is:

script/delayed_job -n 4 -m start 

-m starts monitoring processes that spawn a new delayed_job process if it dies.

The command I use to stop:

 script/delayed_job stop 

But this does not stop the monitoring processes, which, in turn, start all the processes again. I just wish they left. I can kill them with what I have, but I was hoping there was a command line option to just close it all.

Answer 1

In my deployment of capistrano script, I have this:

 desc "Start workers" task :start_workers do run "cd #{release_path} && RAILS_ENV=production script/delayed_job -m -n 2 start" end desc "Stop workers" task :stop_workers do run "ps xu | grep delayed_job | grep monitor | grep -v grep | awk '{print $2}' | xargs -r kill" run "cd #{current_path} && RAILS_ENV=production script/delayed_job stop" end 

To avoid errors that can stop the deployment of the script:

• "ps xu" shows only processes belonging to the current user.
• "xargs -r kill" only calls the kill command when there is something to kill

I just kill the delayed_job monitor and stop the delayed_job daemon in the usual way.

Answer 2

I had the same problem. Here's how I solved it:

 # ps -ef | grep delay root 8605 1 0 Jan03 ? 00:00:00 delayed_job_monitor root 15704 1 0 14:29 ? 00:00:00 dashboard/delayed_job root 15817 12026 0 14:31 pts/0 00:00:00 grep --color=auto delay 

Here you see the delayed_job and process. Then I will manually kill these processes and delete the PID. From the application directory (/ usr / share / puppet in my case):

# ps -ef | grep delay | grep -v grep | awk '{print $2}' | xargs kill && rm tmp/pids/*

Answer 3

The direct answer is that you must first kill the monitor process. However, AFAIK is not easy to do, I don’t think that the PIDs of the monitor are stored anywhere, and starting and stopping the DJ script, of course, does nothing reasonable there, as you noticed.

It seemed strange to me that the monitor function is turned on - I think Daemons has this so that someone writes a DJ script, decided that they just pass this option. But it is not very useful as it is.

I wrote an email to the list about this a while ago, did not receive a response: https://groups.google.com/d/msg/delayed_job/HerSuU97BOc/n4Ps430AI1UJ

You can learn more about monitoring with Daemons here: http://daemons.rubyforge.org/classes/Daemons.html#M000004

If you came up with a better answer / solution, add it to the wiki here: https://github.com/collectiveidea/delayed_job/wiki/monitor-process