Hypnotoad vs el Despliegue systemd
La ruta estándar de producción no usa para nada el archivo de configuración de hypnotoad: la unidad systemd chinaski@<N> lanza cms.pl daemon -l ${LISTEN_URL} con los workers/límites codificados en la propia unidad.
Lo que el patrón systemd evita respecto a ejecutar hypnotoad directamente:
- Stop/restart/reload es trabajo de systemd: Restart=on-failure (con back-off, 5 intentos en un minuto de fallos y luego una parada dura), timeouts de stop dimensionados para que las peticiones en curso y los procesos de build se drenen antes del shutdown (330 s de gracia al detener).
- Límites y hardening: techos de memoria, cuotas de CPU, límites de tareas y un sandbox del sistema de archivos vienen de la unidad, no de la configuración del servidor.
- Entorno por instancia: la
LISTEN_URLde cada instancia (debe ser loopback en producción) y suCHINASKI_SECRETvienen de/etc/chinaski<N>/env: un patrón que soporta cualquier número de instancias desde un solo archivo de unidad.
A cambio, las dos características que hacen distintivo el modo puro de hypnotoad no aplican: no hay recarga USR2 sin downtime (en su lugar, restart (un stop/start duro)), y no hay configuración de graceful time incluida. La política de stop de la unidad systemd lo cubre.
El contenido del archivo de entorno lo lee la unidad al arrancar (un archivo faltante no es fatal durante la configuración inicial, ya que la unidad trae un EnvironmentFile=... de plantilla). Este es el modo estándar de producción; el modo hypnotoad directo existe para los casos offline/de una sola máquina donde systemd no entra en el panorama.