Tu fais exprès ou t'as jamais lu le "Advanced Programming in the Unix Environment" de feu Dr Stevens ?_
Un daemon unix est sensé recharger sa configuration quand on lui envoie le signal SIGHUP,_
J'imagine que tu fais référence au chapitre 13.6
To avoid this, some daemons will catch SIGHUP and reread their configuration files when they receive the signal. Since they aren't associated with terminals and are either session leaders without controlling terminals or members of orphaned process groups, daemons have no reason to expect to receive SIGHUP. Thus, they can safely reuse it.
Si c'est bien le cas
a) Il s'agit de conventions, pas de normes. L'utilisation de sighup pour recharger la config est un hack. C'est d'ailleurs mentionné dans le texte.
b) Dans le cas d'un proxy (surtout en mode load balancing) ca n'a pas vraiment de sens de garder les process actifs vivants au moment d'un changement de config - et comme haproxy est en mode processus unique architecturalement, forcément il redémarre (d'ailleurs Nginx redémarre tous les workers en cas de changement de config, qu'il soit en mode proxy ou non)
c) Haproxy est très correctement écrit, il a des perfs monstrueuses, fonctionne sans failles connues depuis 2002, est utilisé par des milliers de serveurs à travers le monde etc.
Son architecture processus unique le rend incompatible avec systemd sans un wrapper - ca n'est ni un défaut de haproxy, ni pour le coup réellement un défaut de systemd. Ca serait mieux si on pouvait passer des commandes aux serveurs directement via systemctl (des commandes non interprétées je veux dire) mais ca n'est pas possible (cette fois par design de systemd).
[^] # Re: systemd a bon dos
Posté par Kaane . En réponse au journal et ce qui devait arriver, arriva .... Évalué à 10.
J'imagine que tu fais référence au chapitre 13.6
Si c'est bien le cas
a) Il s'agit de conventions, pas de normes. L'utilisation de sighup pour recharger la config est un hack. C'est d'ailleurs mentionné dans le texte.
b) Dans le cas d'un proxy (surtout en mode load balancing) ca n'a pas vraiment de sens de garder les process actifs vivants au moment d'un changement de config - et comme haproxy est en mode processus unique architecturalement, forcément il redémarre (d'ailleurs Nginx redémarre tous les workers en cas de changement de config, qu'il soit en mode proxy ou non)
c) Haproxy est très correctement écrit, il a des perfs monstrueuses, fonctionne sans failles connues depuis 2002, est utilisé par des milliers de serveurs à travers le monde etc.
Son architecture processus unique le rend incompatible avec systemd sans un wrapper - ca n'est ni un défaut de haproxy, ni pour le coup réellement un défaut de systemd. Ca serait mieux si on pouvait passer des commandes aux serveurs directement via systemctl (des commandes non interprétées je veux dire) mais ca n'est pas possible (cette fois par design de systemd).