Nuestro watchdog reinició los servicios que habíamos detenido a propósito
Operaciones
Uno de nuestros watchdogs arranca cualquiera de nuestros servicios que esté habilitado pero no en ejecución. Dos veces en octubre arrancó servicios que habíamos detenido a propósito. La segunda vez, los visitantes de uno de nuestros sitios recibieron errores durante unos 45 minutos.
Por qué existe ese watchdog
Un servicio que sale limpiamente al recibir SIGTERM, por ejemplo porque algo lo mató por nombre, no está «fallido» para systemd. Restart=on-failure no lo recupera, y systemctl --failed no lo lista. Permanece caído hasta que alguien se da cuenta por casualidad. Así que el watchdog busca servicios habilitados pero no en ejecución, y los arranca.
El problema es que un servicio que detuviste manualmente se ve exactamente igual.
La primera vez
El 7 de octubre detuvimos un worker de vídeo con systemctl stop a las 12:47 para editar su cola de trabajos. A las 12:55 estaba ejecutándose de nuevo: el watchdog lo había arrancado.
La segunda vez
El 21 de octubre necesitábamos la memoria de la máquina que también sirve dos de nuestros sitios para una prueba de modelo. Un script detuvo las aplicaciones web de los sitios, un trabajo de sincronización y un contenedor de base de datos, de nuevo con systemctl stop. Unos cinco minutos después, un timer que vigila los sitios, y a las 19:14 el watchdog, volvieron a levantar el túnel y las aplicaciones web.
El túnel volvió a recibir tráfico, pero las aplicaciones web no podían responder: el modelo bajo prueba ocupaba 114 GiB de la memoria de la máquina. Desde las 19:14 hasta las 20:00, algunos visitantes recibieron errores 502. A las 20:00 deshabilitamos el túnel, las aplicaciones web y el trabajo de sincronización, y detuvimos el timer de vigilancia.
La regla que usamos ahora
- Pausa un servicio deshabilitándolo:
sudo systemctl disable --now <unit>. Vuelve a activarlo consudo systemctl enable --now <unit>. Nuestro watchdog solo mira los servicios habilitados, así que deja en paz a los deshabilitados. - Pausa todo lo que pueda recuperarlo: el túnel que tiene delante y cualquier timer que lo vigile.
- Una parada corta es una carrera. Si solo usas
stop, termina antes de la siguiente comprobación, que en nuestras máquinas llega en cuestión de minutos.
Dos trampas más de systemd de los mismos meses
systemctl mask --runtimeno hace nada con un archivo de unidad en /etc/systemd/system. Las unidades en /etc tienen prioridad sobre el enmascaramiento en tiempo de ejecución en /run, por lo que el comando se ejecuta correctamente pero el servicio sigue iniciándose. Para detener un servicio, usamos un drop-in conConditionPathExists=!/etc/<name>.hold: mientras ese archivo exista, el servicio no se iniciará, ni al arrancar ni manualmente.systemctl is-activeconsidera inactivo un servicio oneshot en ejecución. Mientras un servicioType=oneshotse ejecuta, su estado es "activating", por lo queis-activemuestra ese valor y devuelve 3. Un bucle comowhile systemctl is-active --quiet job.service; do sleep 60; done, pensado para esperar a un trabajo nocturno, termina de inmediato. Lee el estado en su lugar: active, activating, reloading o deactivating significan todos que sigue en marcha.
Factory Floor vigila los servicios habilitados que no se están ejecutando. Por defecto solo los informa, y solo los inicia si activas esa opción. Desde la versión 1.0.3, su alerta también indica cómo pausar un servicio a propósito, y su runbook dice lo mismo.