¿Cómo hacer que este conjunto de comandos (para reiniciar un servidor) sea más fácil?

Question

Estoy ejecutando Nginx, FCGI y Request Tracker en un servidor Debian Jessie. Nginx ofrece Request Tracker, pero FCGI se encuentra entre ellos. Lo importante es que el servidor FCGI a veces falla, lo que hace que los usuarios de RT vean un error 502. La solución es bastante simple, pero sólo porque lo he hecho innumerables veces durante el último mes. Si no estoy presente y alguien más tiene que reiniciar el servidor FCGI, es posible que tenga dificultades. Además, detener y reiniciar el servidor es molesto, pero debes hacerlo para aplicar cambios en RT.

Todo eso me lleva a esto: ¿cómo puedo hacer que los comandos sean más fáciles? ¿Un guión? Un servicio, por lo que vive en /etc/init.d? ¿Algo más? Soy nuevo en Debian y en Linux en general, así que no conozco realmente mis opciones ni cuán involucradas podrían ser cada una. Estos son los comandos que debes emitir:

netstat -antp | grep LIST | grep 12345

(Esto encuentra el servidor FCGI vinculado al puerto 12345, por lo que puedo obtener el PID. Digamos que nuestro PID es 8091).

kill 8091
spawn-fcgi -u someUser -g someGroup -a 127.0.0.1 -p 12345 /opt/rt4/sbin/rt-server.fcgi

Una nota importante aquí es que el netstatcomando no puede devolver nada. Si es así, el servidor FCGI ha fallado silenciosamente, por lo que omite el killcomando y va directamente al spawn-fcgiindicado. De lo contrario, mantienes el killcomando.

Idealmente, me encantaría tener opciones de inicio/parada/reinicio para algo como /etc/init.d/rt-fcgi-server. Sin embargo, no tengo idea de qué hacer para detener el proceso debido a la necesidad de encontrar el PID primero. He pensado en usar un .pidarchivo, pero no sé cómo decirlo spawn-fcgiy qué hacer con dicho archivo, incluso si lo tuviera. Ni siquiera sé si haría lo que quiero (conservar el PID para evitar usar el netstatcomando).

Espero que todo esto tenga sentido. Básicamente quiero tener un comando, o algo vinculado /etc/init.d, para controlar el resultado del spawn-fcgicomando. Quiero que los usuarios no root, que saben menos sobre Linux que yo, puedan iniciar sesión y ejecutar un solo comando, y no me importaría una forma de consultar el estado de este proceso sin usar netstat, incluso si No es necesario obtener el PID para eliminarlo. De esta manera puedo usar algo como Monit para reiniciar automáticamente el servidor en caso de que falle.

Answer 1

Voy a escribir esta respuesta desde una perspectiva de FreeBSD, pero debería ser aplicable a Linux y Debian... los nombres de los paquetes y todo eso pueden cambiar.

Yo estaba igualmente disgustado con spawn-fcgi. En FreeBSD, tiene un script rc.d, pero no obedece las reglas de rc.d (por ejemplo, no puede "reiniciar").

Sin embargo, al final del manual de spawn-fcgi se menciona supervisar. Con algunas búsquedas, se reveló "daemontools"... En FreeBSD, había paquetes para daemontools y daemontools-encore. El -encore parecía ser más nuevo y poseía más funciones, así que lo elegí. Mi versión es 1.10_1 de daemontools-encore.

En FreeBSD, se proporciona un script rc.d para svscan. En FreeBSD, esto escanea /var/service en busca de subdirectorios y ejecuta una "supervisión" para cada uno. Acepté esta configuración predeterminada y puse svscan_enable="YES"/etc/rc.conf. Para Linux, no conozco el script rc, pero dice que /service es el directorio predeterminado.

Dentro de /var/service, creé rt-fcgi y dentro de rt-fcgi creé run. "ejecutar" contiene:

#!/bin/sh

spawn-fcgi -u www -g www -s /tmp/rt.sock -n -- /usr/local/sbin/rt-server.fcgi

Obviamente, en Linux, esto debe tener el usuario y el grupo que estás usando y la ubicación de tu rt-server.fcgi.

El sistema svscan parece anunciar las últimas líneas de error en el título de un proceso. Hay otras opciones. El mío se parece a:

46495  -  IJ   0:00.01 /usr/local/bin/readproctitle service errors: ...tory (/var/run/rt44/data/gpg). GnuPG support has been disabled (/usr/local/lib/perl5/site_perl/RT/Config.pm:790)\n[52465] [Tue Mar  7 21:09:54 2017] [warning]: The requested port (443) does NOT match the configured WebPort (80).  Perhaps you should Set($WebPort, 443); in RT_SiteConfig.pm, otherwise your internal hyperlinks may be broken. (/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:1328)\n

... lo que significa que no tengo gupg configurado correctamente. Parece que podría buscar errores y todo eso a menos que configure el registro para svscan.

Esta es una parte bastante dura para un fcgi, pero está enlatada y funciona. Se ocupa de la salida del script por cualquier motivo, pero no administra un archivo PID o el socket (aparte de crear el archivo de socket).

Debo decir que estoy mucho más enamorado del estándar WSGI que de este desastre.