¿Cómo detengo el retraso de trabajo si lo estoy ejecutando con la opción -m "monitor"?

¿Cómo detengo el retraso de trabajo si lo estoy ejecutando con la opción -m "monitor"? ¡Los procesos siguen siendo reiniciados!¿Cómo detengo el retraso de trabajo si lo estoy ejecutando con la opción -m "monitor"?

El comando de empezar con delayed_job es:

script/delayed_job -n 4 -m start

El -m corre a monitorear los procesos que genera un nuevo proceso de delayed_job si uno muere.

El comando que estoy usando para detener la reacción es:

script/delayed_job stop

Pero eso no impide que los procesos de monitor, que a su vez ponen en marcha todos los procesos de nuevo. Me gustaría que se vayan. Puedo matarlos, lo cual tengo, pero esperaba que hubiera alguna opción de línea de comando para cerrar todo.

Fuente

2011-10-13 AKWF

En mi Capistrano desplegar la escritura tengo esto:

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

Para evitar cualquier error que pueda detener la secuencia de comandos de implementación:

"PS" xu mostrar sólo los procesos pertenecientes al usuario actual
"xargs -r matan "solo invocar el comando kill cuando hay algo que matar

Solo elimino el monitor delayed_job y detengo el delayed_job deamon de la manera normal.

Fuente

2012-04-05 08:08:34 Joris

Mato los procesos de trabajo retrasados de la manera normal y luego obligo a matar a los rezagados solo para asegurarme. En capistrano 3, estoy usando 'execute' en lugar de' run' – Dex

La respuesta directa es que primero tiene que matar el proceso del monitor. Sin embargo, AFAIK no es una forma fácil de hacerlo, no creo que los PID de monitor estén almacenados en ningún lado y el script de inicio y finalización de DJ ciertamente no hace nada inteligente allí, como habrás notado.

Me resulta extraño que se haya incluido la función del monitor, supongo que Daemons lo tiene así que quienquiera que escribiera el guión de DJ pensó que simplemente dejarían esa opción. Pero no es realmente útil como es.

me escribió un correo electrónico a la lista de esto un tiempo atrás, no obtuvo una respuesta: https://groups.google.com/d/msg/delayed_job/HerSuU97BOc/n4Ps430AI1UJ

se puede ver más información sobre la vigilancia con Demonios aquí: http://daemons.rubyforge.org/classes/Daemons.html#M000004

Si usted viene con una mejor respuesta/solución, agréguela al wiki aquí: https://github.com/collectiveidea/delayed_job/wiki/monitor-process

Fuente

2011-10-14 02:12:04

Parece que las cosas han cambiado en los tres años desde que se dio esta respuesta. Usando retrayed_job 4.0.2, cuando -m se pasa a 'delayed_job -m start', tanto delayed_job.pid como delayed_job_monitor.pid se escriben en tmp/pids, y 'demorado_el trabajo detenido' mata ambos procesos. – KenB

Tuve este mismo problema. Así es como lo resolví:

# 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

Aquí puede ver el proceso de delayed_joby el monitor. A continuación, eliminaría manualmente estos procesos y luego eliminaría los PID. Desde el directorio de la aplicación (/ usr/share/marioneta-tablero en mi caso):

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

Fuente

2012-01-05 14:40:37 Justin

¿Cómo detengo el retraso de trabajo si lo estoy ejecutando con la opción -m "monitor"?

Respuesta

Cuestiones relacionadas