¿Manera simple de reiniciar procesos bloqueados?

10

Necesito monitorear varios procesos que se ejecutan en mi servidor web. Por alguna razón, el barniz se bloquea actualmente una vez al día o dos. Estoy usando monit para supuestamente reiniciar el barniz automáticamente, pero no funciona. Aquí está mi entrada monit.conf para Varnish.

check process varnish with pidfile /var/run/varnish.pid
    start program = "/etc/init.d/varnish start" with timeout 60 seconds
    stop program = "/etc/init.d/varnish stop"
    if failed host <my server ip> port 80 protocol http
        and request "/blank.html" then restart
    if 3 restarts within 5 cycles then timeout
    group server

El archivo de registro muestra que después de que el barniz deja de ejecutarse, el intento de reinicio luego falla. Luego, finalmente, monit deja de monitorear el barniz.

¿Alguien tiene sugerencias sobre cómo puedo solucionar esto? O mejor aún, ¿puede sugerir otras formas simples de monitorear y reiniciar automáticamente los procesos bloqueados? ¡Gracias!

linux web-server monitoring varnish monit Lin
fuente
No puedo creer lo difícil que eran tales cosas en tiempos pre-sistematizados.
Fl0v0

Respuestas:

17

Buscaría en daemontools ( http://cr.yp.to/daemontools.html ).

Supervise se creó exactamente para este propósito: iniciar procesos y observarlos, reiniciándolos de inmediato si alguna vez terminan.

Aún puede usar monit si necesita hacer algo más complicado que una simple verificación de "todavía se está ejecutando", y si el proceso necesita reiniciarse, hágalo mediante supervisión.

Ian Clelland
fuente
También uso las herramientas daemontools para monitorear procesos de servicios inestables. Muy útil si tuviera que decirlo. :-)
edomaur
2

Puede usar scripts de controlador de eventos con Nagios si lo tiene para reiniciar los servicios.

Si el barniz requiere permiso de root para comenzar (los scripts init.d generalmente lo hacen) cambie "/etc/init.d/varnish start" a "sudo /etc/init.d/varnish start". Pero eso probablemente no sea suficiente, ya que probablemente no desee otorgar a monit de usuario los privilegios totales de sudo nopasswd a todos los comandos y dar sudo a un script de shell sería básicamente igual de malo. Por lo tanto, tendrá que averiguar qué comandos en ese script de inicio necesitan sudo, otorgarle privilegios de sudo en el archivo / etc / sudoers al usuario monit y finalmente editar ese script de inicio en consecuencia. ¿O tal vez en lugar de todo este barniz se puede ejecutar como usuario no root?

Finalmente, estoy seguro de que sabes esto, pero lo diré de todos modos. Claramente está poniendo mucho esfuerzo en esto, espero que esté haciendo tanto esfuerzo para descubrir por qué el barniz se está bloqueando y en realidad lo está arreglando (o persiguiendo a los desarrolladores para que descubran por qué) :-)

Actualización:
Esto podría no ser tan limpio, pero una forma fácil de hacerlo como root podría ser configurar un script que verifique si el proceso está bien, y si no lo inicia. Luego solo ejecuta ese script cada dos minutos como un trabajo cron.

Kyle Brandt
fuente
Al principio consideré a Nagios, pero quería algo pequeño y simple para mis propósitos. Y sí, estoy investigando el problema del barniz. Uno de mis servidores lo ha mantenido estable durante mucho tiempo, por lo que definitivamente tiene que ver conmigo. :(
Lin
1

Otro gran método tomado de StackOverflow :

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

Esto podría agregarse al crontab:

crontab -e

Luego agregue una regla para iniciar su script de monitor:

@reboot /usr/local/bin/myservermonitor

O agregado como un script en /etc/init.d

Consulte la respuesta de StackOverflow para obtener una explicación detallada de por qué este es un buen enfoque.

Cory Klein
fuente
0

También estaba buscando la forma más sencilla de manejar este problema. La forma más fácil que podría encontrar es simplemente agregar Restart=allwaysal .servicearchivo correspondiente en la /etc/systemd/system/multi-user.target.wants/última línea de la [service]etiqueta.

Después de eso, sudo systemctl daemon-reloadsiga sudo systemctl restart service.servicepara volver a cargar los cambios.

Puede probar comprobando si el servicio se está ejecutando: systemctl status processnamecompruebe la marca de tiempo de inicio. Después de eso ps -ef | grep servicename, elimine el proceso con la identificación que acaba de encontrar kill 1234. después de eso, systemctl status processnamevuelva a hacer y verifique si la marca de tiempo de inicio está actualizada.

Debería funcionar en:

  • Debian 7 y Debian 8
  • Ubuntu 15.04 y más reciente
  • CentOS 7 y futuros
RoDo
fuente