rails deploy california ruby-on-rails background capistrano nohup

ruby-on-rails - deploy - capistrano rails



Iniciando tareas de fondo con capistrano. (4)

Para mi aplicación RubyOnRails tengo que comenzar un trabajo de fondo al final de la implementación de Capistrano. Para esto, probé lo siguiente en deploy.rb:

run "nohup #{current_path}/script/runner -e production ''Scheduler.start'' &", :pty => true

A veces esto funciona, pero la mayoría de las veces no inicia el proceso (= no se muestra en ps -aux). Y no hay mensajes de error. Y no hay nohup.out, no en el directorio de inicio y no en el directorio de aplicaciones de Rails.

Intenté usar trap (''SIGHUP'', ''IGNORE'') en scheduler.rb en lugar de nohup, pero el resultado es el mismo.

La única forma de hacerlo funcionar es eliminando ": pty => true" y hacer un Ctrl-C manual al final de "Cap deploy". Pero no me gusta esto ...

¿Hay otras posibilidades de invocar este Scheduler.start? ¿O para obtener más mensajes de error?

Estoy usando Rails 2.3.2, Capistrano 2.5.8, Ubuntu Hardy en el servidor


¿Desea que su trabajo de Scheduler se ejecute continuamente en segundo plano y se reinicie cuando ejecuta Capistrano?

Si es así, entonces para eso uso runit http://smarden.sunsite.dk/runit/ y DelayedJob http://github.com/Shopify/delayed_job/tree/master

  1. Instale runit en el modo de no reemplazar init
  2. Agregue su trabajo en segundo plano como un servicio runit y agregue el monitor de registro para él desde runit.
  3. Haga que Capistrano llame a sudo sv kill nombre_trabajo para matar y reiniciar el trabajo.

Mi trabajo de fondo es una instancia del complemento DelayedJob de Rails que maneja las tareas de Rails en segundo plano. Lo mato con cada implementación de Capistrano para que se reinicie con el código base actualizado.

Esto ha demostrado ser muy confiable.

HTH,

Larry


Con: pty => true, los scripts de inicio del shell de usuario (por ejemplo, bashrc, etc.) no están (generalmente) cargados. Mi programa ruby ​​salió justo después del lanzamiento debido a la falta de variables de entorno dependientes.

Sin: pty => verdadero, como describiste en la pregunta, el capistrano se cuelga allí esperando que salga el proceso. Tendrá que redireccionar stdout y stderr para hacer que regrese inmediatamente.

run ''nohup ruby -e "sleep 5" &'' # hangs for 5 seconds run ''nohup ruby -e "sleep 5" > /dev/null &'' # hangs for 5 seconds run ''nohup ruby -e "sleep 5" > /dev/null 2>&1 &'' # returns immediately. good.

Si su tarea en segundo plano todavía no se ejecuta. Intente redirigir stdout y stderr a un archivo de registro para que pueda investigar la salida.


Me gustaría compartir mi solución que también funciona cuando se ejecutan varios comandos. Probé muchas otras variantes encontradas en línea, incluido el truco "Sleep N".

run("nohup sh -c ''cd #{release_path} && bundle exec rake task_namespace:task_name RAILS_ENV=production > ~/shared/log/<rakelog>.log &'' > /dev/null 2>&1", :pty => true)

Este es un proceso en segundo plano de lanzamiento de respuesta dup en la tarea de capistrano, pero queremos asegurarnos de que otros y yo podamos buscar esta solución en Google.


Si este programador de tareas tiene un modificador -d, funcionará. Por ejemplo, el pasajero independiente tiene una opción -d para iniciarlo como un proceso demonizado.

namespace :passenger_standalone do task :start do run "cd #{current_path} && passenger start -e #{rails_env} -d" end task :stop do run "cd #{current_path} && RAILS_ENV=#{rails_env} passenger stop" end task :restart do stop start end end