Tenemos que usar el trabajo demorado (o algún otro procesador de fondo de trabajo) para ejecutar trabajos en segundo plano, pero no podemos cambiar las secuencias de arranque/arranque -levels en el servidor. Esto significa que no se garantiza que el daemon permanezca disponible si el proveedor reinicia el servidor (ya que el daemon se habría iniciado con una receta capistrano que solo se ejecuta una vez por implementación).Comience o asegúrese de que la tarea retrasada se ejecuta cuando una aplicación/servidor se reinicia
Actualmente, la mejor manera en que puedo pensar para asegurarme de que el demonio delayed_job siempre se está ejecutando, es agregar un inicializador a nuestra aplicación Rails que comprueba si el daemon se está ejecutando. Si no se está ejecutando, el inicializador inicia el daemon, de lo contrario, simplemente lo deja.
La pregunta, por lo tanto, es ¿cómo detectamos que el daemon Delayed_Job se ejecuta desde dentro de un script? (Deberíamos ser capaces de iniciar un daemon con bastante facilidad, pero no sé cómo detectar si uno ya está activo).
¿Alguien tiene alguna idea?
Saludos, Bernie
Sobre la base de la respuesta de abajo, esto es lo que ocurrió. Sólo hay que poner en config/inicializadores y ya está todo listo:
#config/initializers/delayed_job.rb
DELAYED_JOB_PID_PATH = "#{Rails.root}/tmp/pids/delayed_job.pid"
def start_delayed_job
Thread.new do
`ruby script/delayed_job start`
end
end
def process_is_dead?
begin
pid = File.read(DELAYED_JOB_PID_PATH).strip
Process.kill(0, pid.to_i)
false
rescue
true
end
end
if !File.exist?(DELAYED_JOB_PID_PATH) && process_is_dead?
start_delayed_job
end
En su respuesta, ¿no deberíamos también suministrar '-e production'? – nathanvda
Usando rails3 esta solución no funciona para mí. Comenzar el proceso va completamente mal: sigue empezando trabajos adicionales. Estoy de vuelta a las tareas de capistrano :) – nathanvda