Receta para DelayedJob

Hola comunidad, tal vez alguien pueda compartirme la receta de
capistrano
para iniciar y parar el ‘job runner’ de DelayedJob, estoy usando esta
pero
no me funciona:

desc “Stop the job runner”
task :stop_job_runner , :roles => :app do
run “ps ux | awk ‘/job_runner/ && !/awk/ {print $2}’ |xargs -i kill {}
2&>/dev/null”
end

desc “Start the job runner”
task :start_job_runner , :roles => :app do
run “cd #{current_path} && RAILS_ENV=production nohup
./script/job_runner
&”
end

Cada vez que deployo no llega a levantar el ‘job runner’, pero si
ejecuta el
mismo comando via ssh levanta sin ningun problema, he tratado de
manejarlo
mediante God, pero no me funciona bien, me parece que es debido a que le
he
pasado mal la ruta al PID ya que no se donde se encuentra.

Saludos.

Le dices a capistrano que despues de hacer el deploy inicie el runner?
Algo como por ejemplo:

task :after_deploy do
  deploy.start_job_runner
end

2008/7/23 Ruben. D. [email protected]:

Hola comunidad, tal vez alguien pueda compartirme la receta de capistrano
para iniciar y parar el ‘job runner’ de DelayedJob, estoy usando esta pero
no me funciona:

Cada vez que deployo no llega a levantar el ‘job runner’, pero si ejecuta el
mismo comando via ssh levanta sin ningun problema, he tratado de manejarlo
mediante God, pero no me funciona bien, me parece que es debido a que le he
pasado mal la ruta al PID ya que no se donde se encuentra.

Hay diversas maneras de gestionar la cola. Me he intercambiado unos
emails con el desarrollador de RudeQ, parecido a delayed_jobs pero con
una API similiar a la de Starling y el lo hace ejecuando un proceso
que vacia la cola cada 2 minutos, con un cron que llama a una Rake
task … cosa que cada vez carga todo el framework Rails. Yo por
ejemplo opté por deamonizar el proceso que se encarga de procesar la
cola, así solo arranco Rails una sola vez.

Lo de God para gestionar el proceso esta muy bien, pero dependes de
God, del que he oido cosas buenas, y otras no tan buenas como por
ejemplo el consumo de memoria.

Para controlar los procesos de Ruby puedes utilizar la gema deamonize
de manera que podrias arrancar el procesado de colas con
script/runner. La gema se encarga de que puedas arrancar el proceso,
pararlo, reiniciarlo … i tambien de crear el pid file … etc.

Hola Francesc, si le indico a capistrano que reinicie el proceso:

desc “Restart the job runner”
task :restart_job:runner, :roles => :app do
stop_job_runner
start_job_runner
end

namespace :deploy do

task :restart do
restart_job_runner

end

end

Las tareas se llegan a ejecutar bien segun el log que me tira capistrano
al
deployar, lo que no entiendo es porque no lleva a iniciar el job runner
y
cuando ejecuto el comando por ssh.

He investigado varias maneras para manejar las tareas en background,
empeze
usando backgroundrb, hasta ayer todo funcionaba bien, pero despues de
una
actualizacion me producia un bloqueo inexplicable en el Mysql aparte de
que
me tiraba muchos recursos, he probado Workling tambien, pero por
extrañas
razones Starling siempre me cogia el puerto de desarrollo a pesar de que
le
pasaba RAILS_ENV=production, en fin, ayer opte por usar DelayedJob, me
gusto
la forma como esta hecho, es bien sencillo y lo mejor es que tengo el
respaldo de que es estable ya que lo usan en la coctelera y unvlog, por
ahora no tengo planeado migrar hacia otro sistema para gestionar las
colas,
solamente quisiera algo sencillo y que funcione.

Gracias.

El día 23 de julio de 2008 14:52, Francesc E. <
[email protected]> escribió:

Al final logre solucionarlo siguiendo esto:
http://rubyisawesome.com/2007/5/6/daemonizing-ruby-scripts-for-monit

A proposito, cuantos frustrados por monit habra aqui?, a mi monit me
funciona cuando quire, aveces todo bien a la primera instalacion, pero
en
este ultimo VPS que trate de configurarlo, no levanto por nada, asi que
no
me quedo otra que usar God, es cierto que se tira regular memoria pero
hace
su trabajo muy bien.

Saludos.

El día 23 de julio de 2008 15:57, Ruben. D. [email protected]
escribió:

Respecto a daemonizar (si se me permite el palabro), prefiro usar el
star-stop-daemon de debian. Ya que de una sola pasada me asegura que
no se esté ejecutando ya por la comprobación del pid. Un simple cron,
me puede lanzar dos veces el mismo proceso.

Una vez que he definido start-stop-daemon con sus parámetros, creo un
archivo de arranque en /etc/init.d que lo lance mediante
start-stop-daemon y luego dejo a monit que haga el resto (del que
respondiendo a tu pregunta, nunca he tenido ningún problema).

El script de arranque es más fácil de lo que parece, y te pego el
esquema de uno usando el start-stop-daemon de debian, que simplifica
bastante la cosa. Está recortado y resumido. Le puedes fácilmenta
añadir tareas. Por ejemplo en tu caso le puedes añadir un comando para
que te diga el número de trabajos en cola, que te puede ser útil para
pasárselo como parámetro de entrada a un cron que haga rrd y sacar
fácilmente gráficas sobre el uso.
Por ejemplo
/etc/init.d/delayed_jobs jobs_count

Espero que te le sirva a alguien.
PD: Perdón por el off-topic ya que esto es más de sistemas que de rails.

Un Saludo

begin /etc/init.d/serviceX ----
#!/bin/bash
PROGRAM=/usr/local/bin/program
PIDFILE=/var/run/program.pid
USER=guillermo

if ! [ -x $PROGRAM]; then
exit 0
fi

case “$1” in
start)
echo -n “Starting server:”
/sbin/start-stop-daemon --start --quiet --pidfile $PIDFILE
–chdir /var/sphinx -c $USER --exec $PROGRAM
echo “.”
;;
stop)
echo -n “Stopping server:”
/sbin/start-stop-daemon --stop --quiet --oknodo --pidfile
$PIDFILE -c $USER --exec $PROGRAM
echo “.”
;;
reload)
echo -n “Reloading server:”
/sbin/start-stop-daemon --stop --quiet --oknodo --pidfile
$PIDFILE --signal 1
echo “.”
;;
restart)
echo -n “Restarting server:”
/sbin/start-stop-daemon --stop --quiet --oknodo --pidfile
$PIDFILE -c $USER --exec $PROGRAM
/sbin/start-stop-daemon --start --quiet --pidfile $PIDFILE
–chdir /etc -c $USER --exec $PROGRAM
echo “.”
;;
*)
echo “Usage: $0 {start|stop|restart}”
exit 1
;;

esac

exit 0

vale Guillermo, vaya he armado varias veces scripts de arranque y no se
me
ocurria esto.

Gracias!

El día 23 de julio de 2008 19:00, Guillermo [email protected]
escribió:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs