¿Cómo escribo un script bash para reiniciar un proceso si muere?

Tengo un script de Python que verificará una cola y realizará una acción en cada elemento:

# checkqueue.py
while True:
  check_queue()
  do_something()

¿Cómo escribo un script bash que verificará si se está ejecutando y, si no, inícielo? Aproximadamente el siguiente pseudocódigo (¿o tal vez debería hacer algo así ps | grep?):

# keepalivescript.sh
if processidfile exists:
  if processid is running:
     exit, all ok

run checkqueue.py
write processid to processidfile

Llamaré eso desde un crontab:

# crontab
*/5 * * * * /path/to/keepalivescript.sh

Evite los archivos PID, crons o cualquier otra cosa que intente evaluar procesos que no sean sus hijos.

Hay una muy buena razón por la cual en UNIX, SOLO puede esperar a sus hijos. Cualquier método (análisis ps, pgrep, almacenamiento de un PID, ...) que intente solucionarlo es defectuoso y tiene agujeros enormes. Solo di que no .

En su lugar, necesita que el proceso que supervisa su proceso sea el padre del proceso. ¿Qué significa esto? Significa que solo el proceso que inicia su proceso puede esperar confiablemente a que termine. En bash, esto es absolutamente trivial.

until myserver; do
    echo "Server 'myserver' crashed with exit code $?.  Respawning.." >&2
    sleep 1
done

La parte anterior del código bash se ejecuta myserveren un untilbucle. La primera línea comienza myservery espera a que termine. Cuando termina, untilverifica su estado de salida. Si el estado de salida es 0, significa que terminó con gracia (lo que significa que le pidió que se cerrara de alguna manera, y lo hizo con éxito). En ese caso, no queremos reiniciarlo (¡solo le pedimos que se apague!). Si el estado de salida no es 0, untilejecutará el cuerpo del bucle, que emite un mensaje de error en STDERR y reinicia el bucle (de vuelta a la línea 1) después de 1 segundo .

¿Por qué esperamos un segundo? Porque si algo está mal con la secuencia de inicio myservery se bloquea de inmediato, tendrá un ciclo muy intenso de reinicio constante y bloqueo en sus manos. El sleep 1quita la tensión de eso.

Ahora todo lo que necesita hacer es iniciar este script bash (probablemente de forma asincrónica), y lo monitoreará myservery reiniciará según sea necesario. Si desea iniciar el monitor en el arranque (haciendo que el servidor "sobreviva" los reinicios), puede programarlo en el cron de su usuario (1) con una @rebootregla. Abra sus reglas cron con crontab:

crontab -e

Luego agregue una regla para iniciar su script de monitor:

@reboot /usr/local/bin/myservermonitor

Alternativamente; mira inittab (5) y / etc / inittab. Puede agregar una línea allí para myservercomenzar en un cierto nivel de inicio y reaparecer automáticamente.

Editar.

Permítanme agregar información sobre por qué no usar archivos PID. Si bien son muy populares; también son muy defectuosos y no hay razón para que no lo hagas de la manera correcta.

Considera esto:

1. Reciclaje de PID (matar el proceso incorrecto):

   • /etc/init.d/foo start: inicio foo, escriba fooel PID en/var/run/foo.pid
   • Un rato después: foomuere de alguna manera.
   • Un tiempo después: cualquier proceso aleatorio que se inicie (llámelo bar) toma un PID aleatorio, imagínelo tomando fooel PID anterior.
   • Te das cuenta foode que se ha ido: /etc/init.d/foo/restartlee /var/run/foo.pid, verifica si todavía está vivo, lo encuentra bar, piensa que lo foomata, comienza un nuevo foo.

2. Los archivos PID quedan obsoletos. Necesita una lógica demasiado complicada (o debería decir, no trivial) para verificar si el archivo PID está obsoleto y si dicha lógica es nuevamente vulnerable 1..

3. ¿Qué sucede si ni siquiera tiene acceso de escritura o está en un entorno de solo lectura?

4. Es una sobrecomplicación sin sentido; vea cuán simple es mi ejemplo anterior. No hay necesidad de complicar eso, en absoluto.

Ver también: ¿Los archivos PID todavía tienen fallas cuando lo hacen 'bien'?

Por cierto; incluso peor que los archivos PID está analizando ps! Nunca hagas esto.

1. psEs muy inportable. Si bien lo encuentra en casi todos los sistemas UNIX; sus argumentos varían mucho si desea una salida no estándar. ¡Y la salida estándar es SOLO para consumo humano, no para análisis con secuencias de comandos!
2. El análisis psconduce a MUCHOS falsos positivos. ¡Tome el ps aux | grep PIDejemplo, y ahora imagine que alguien comienza un proceso con un número en algún lugar como argumento que resulta ser el mismo que el PID con el que miró a su demonio! Imagina a dos personas que comienzan una sesión X y estás buscando X para matar a la tuya. Es todo tipo de cosas malas.

Si no desea administrar el proceso usted mismo; Existen algunos sistemas perfectamente buenos que actuarán como monitor de sus procesos. Mira en runit , por ejemplo.

Echa un vistazo a monit ( http://mmonit.com/monit/ ). Maneja el inicio, la detención y el reinicio de su secuencia de comandos y puede realizar comprobaciones de estado y reinicios si es necesario.

O haz un script simple:

while true
do
/your/script
sleep 1
done

La forma más fácil de hacerlo es usar flock en el archivo. En el script Python que harías

lf = open('/tmp/script.lock','w')
if(fcntl.flock(lf, fcntl.LOCK_EX|fcntl.LOCK_NB) != 0): 
   sys.exit('other instance already running')
lf.write('%d\n'%os.getpid())
lf.flush()

En shell puedes probar si se está ejecutando:

if [ `flock -xn /tmp/script.lock -c 'echo 1'` ]; then 
   echo 'it's not running'
   restart.
else
   echo -n 'it's already running with PID '
   cat /tmp/script.lock
fi

Pero, por supuesto, no tiene que probar, porque si ya se está ejecutando y lo reinicia, saldrá con 'other instance already running'

Cuando el proceso muere, todos sus descriptores de archivo se cierran y todos los bloqueos se eliminan automáticamente.

Debe usar monit, una herramienta estándar de Unix que puede monitorear diferentes cosas en el sistema y reaccionar en consecuencia.

De los documentos: http://mmonit.com/monit/documentation/monit.html#pid_testing

compruebe el proceso checkqueue.py con pidfile /var/run/checkqueue.pid
       si se cambia pid entonces exec "checkqueue_restart.sh"

También puede configurar monit para que le envíe un correo electrónico cuando reinicie.

if ! test -f $PIDFILE || ! psgrep `cat $PIDFILE`; then
    restart_process
    # Write PIDFILE
    echo $! >$PIDFILE
fi

No estoy seguro de cuán portátil es en todos los sistemas operativos, pero puede verificar si su sistema contiene el comando 'run-one', es decir, "man run-one". Específicamente, este conjunto de comandos incluye 'run-one-constantemente', que parece ser exactamente lo que se necesita.

Desde la página del manual:

ejecutar-uno-constantemente COMANDO [ARGS]

Nota: obviamente, esto podría llamarse desde su script, pero también elimina la necesidad de tener un script.

He utilizado el siguiente script con gran éxito en numerosos servidores:

pid=`jps -v | grep $INSTALLATION | awk '{print $1}'`
echo $INSTALLATION found at PID $pid 
while [ -e /proc/$pid ]; do sleep 0.1; done

notas:

• Está buscando un proceso de Java, por lo que puedo usar jps, esto es mucho más consistente en todas las distribuciones que ps
• $INSTALLATION contiene suficiente de la ruta del proceso que es totalmente inequívoca
• Usa el modo de espera mientras esperas que el proceso muera, evita acaparar recursos :)

Este script se usa para cerrar una instancia en ejecución de tomcat, que quiero cerrar (y esperar) en la línea de comandos, por lo que iniciarlo como un proceso secundario simplemente no es una opción para mí.

Lo uso para mi proceso npm

#!/bin/bash
for (( ; ; ))
do
date +"%T"
echo Start Process
cd /toFolder
sudo process
date +"%T"
echo Crash
sleep 1
done