Hypnotoad vs le déploiement systemd
Le chemin de production standard n'utilise pas du tout le fichier de config de hypnotoad : l'unité systemd chinaski@<N> lance cms.pl daemon -l ${LISTEN_URL} avec workers/limites encodés dans l'unité elle-même.
Ce que le motif systemd contourne par rapport à l'exécution directe de hypnotoad :
- Stop/restart/reload est le travail de systemd : Restart=on-failure (avec back-off, 5 tentatives dans une minute d'échec puis un arrêt dur), des timeouts d'arrêt dimensionnés pour laisser les requêtes en vol et les processus de build se drainer avant l'extinction (330 s de grâce à l'arrêt).
- Limites et durcissement : plafonds mémoire, quotas CPU, limites de tâches, et un sandbox du système de fichiers viennent de l'unité, pas de la configuration du serveur.
- Env par instance : le
LISTEN_URLde chaque instance (doit être loopback en production) etCHINASKI_SECRETviennent de/etc/chinaski<N>/env, un motif qui supporte n'importe quel nombre d'instances depuis un seul fichier d'unité.
En échange, les deux fonctionnalités qui rendent le mode brut de hypnotoad distinctif ne s'appliquent pas : pas de rechargement USR2 sans interruption (redémarrage à la place, un stop/start dur), et pas de config de grace fournie ; la politique d'arrêt de l'unité systemd la couvre.
Le contenu du fichier env est lu par l'unité au démarrage (un fichier manquant n'est pas fatal pendant l'installation initiale, puisque l'unité est fournie avec un template EnvironmentFile=...). C'est le mode standard de production ; le mode hypnotoad direct existe pour les cas offline/mono-machine où systemd ne fait pas partie du tableau.