Tout commence ici : http://marc.info/?l=haproxy&m=135229333418960&w=2
Le gars explique qu'on peut pas faire marcher correctement haproxy avec systemd pour une obscure raison de mise en état "failed" du service en cas de rechargement de la config.
I'm trying to use haproxy with systemd.
It cannot be done with a raw haproxy for now, because when "reloading" the configuration file
with haproxy -sf <pid>, the former process gets killed, so the service enters a "failed" state
and thus kills all its children, resulting in no haproxy running.
In order not to have to make a lot of modifications in the way haproxy currently handles this,
I'm writing a wrapper around it and the corresponding systemd service file. I will provide them
once they are fully ready. (What could be the name of this wrapper, by the way? haproxy-systemd-wrapper?)
This requires a small modification to the haproxy entry point though: In order to be able to track
haproxy state from the wrapper with the double fork' the entry point must not exit after spawning
child processes.
Here is the first patch which introduces this feature.
En suite, on a : http://marc.info/?l=haproxy&m=135229333518962&w=2
diff --git a/src/haproxy.c b/src/haproxy.c
index c6933c3..b7430f8 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -42,6 +42,7 @@
#include <signal.h>
#include <stdarg.h>
#include <sys/resource.h>
+#include <sys/wait.h>
#include <time.h>
#include <syslog.h>
@@ -509,8 +510,11 @@ void init(int argc, char **argv)
arg_mode |= MODE_DEBUG;
else if (*flag == 'c')
arg_mode |= MODE_CHECK;
- else if (*flag == 'D')
+ else if (*flag == 'D') {
arg_mode |= MODE_DAEMON;
+ if (flag[1] == 's') /* -Ds */
+ arg_mode |= MODE_SYSTEMD;
+ }
else if (*flag == 'q')
arg_mode |= MODE_QUIET;
else if (*flag == 's' && (flag[1] == 'f' || flag[1] == 't')) {
@@ -564,7 +568,7 @@ void init(int argc, char **argv)
}
global.mode = MODE_STARTING | /* during startup, we want most of the alerts */
- (arg_mode & (MODE_DAEMON | MODE_FOREGROUND | MODE_VERBOSE
+ (arg_mode & (MODE_DAEMON | MODE_SYSTEMD | MODE_FOREGROUND | MODE_VERBOSE
| MODE_QUIET | MODE_CHECK | MODE_DEBUG));
if (LIST_ISEMPTY(&cfg_cfgfiles))
@@ -715,24 +719,24 @@ void init(int argc, char **argv)
if (arg_mode & (MODE_DEBUG | MODE_FOREGROUND)) {
/* command line debug mode inhibits configuration mode */
- global.mode &= ~(MODE_DAEMON | MODE_QUIET);
+ global.mode &= ~(MODE_DAEMON | MODE_SYSTEMD | MODE_QUIET);
global.mode |= (arg_mode & (MODE_DEBUG | MODE_FOREGROUND));
}
- if (arg_mode & MODE_DAEMON) {
+ if (arg_mode & (MODE_DAEMON | MODE_SYSTEMD)) {
/* command line daemon mode inhibits foreground and debug modes mode */
global.mode &= ~(MODE_DEBUG | MODE_FOREGROUND);
- global.mode |= (arg_mode & MODE_DAEMON);
+ global.mode |= (arg_mode & (MODE_DAEMON | MODE_SYSTEMD));
}
global.mode |= (arg_mode & (MODE_QUIET | MODE_VERBOSE));
- if ((global.mode & MODE_DEBUG) && (global.mode & (MODE_DAEMON | MODE_QUIET))) {
- Warning("<debug> mode incompatible with <quiet> and <daemon>. Keeping <debug> only.\n");
- global.mode &= ~(MODE_DAEMON | MODE_QUIET);
+ if ((global.mode & MODE_DEBUG) && (global.mode & (MODE_DAEMON | MODE_SYSTEMD | MODE_QUIET))) {
+ Warning("<debug> mode incompatible with <quiet>, <daemon> and <systemd>. Keeping <debug> only.\n");
+ global.mode &= ~(MODE_DAEMON | MODE_SYSTEMD | MODE_QUIET);
}
- if ((global.nbproc > 1) && !(global.mode & MODE_DAEMON)) {
+ if ((global.nbproc > 1) && !(global.mode & (MODE_DAEMON | MODE_SYSTEMD))) {
if (!(global.mode & (MODE_FOREGROUND | MODE_DEBUG)))
Warning("<nbproc> is only meaningful in daemon mode. Setting limit to 1 process.\n");
global.nbproc = 1;
@@ -1341,7 +1345,7 @@ int main(int argc, char **argv)
}
/* open log & pid files before the chroot */
- if (global.mode & MODE_DAEMON && global.pidfile != NULL) {
+ if (global.mode & (MODE_DAEMON | MODE_SYSTEMD) && global.pidfile != NULL) {
unlink(global.pidfile);
pidfd = open(global.pidfile, O_CREAT | O_WRONLY | O_TRUNC, 0644);
if (pidfd < 0) {
@@ -1423,7 +1427,7 @@ int main(int argc, char **argv)
argv[0], (int)limit.rlim_cur, global.maxconn, global.maxsock, global.maxsock);
}
- if (global.mode & MODE_DAEMON) {
+ if (global.mode & (MODE_DAEMON | MODE_SYSTEMD)) {
struct proxy *px;
int ret = 0;
int proc;
@@ -1466,8 +1470,11 @@ int main(int argc, char **argv)
px = px->next;
}
- if (proc == global.nbproc)
+ if (proc == global.nbproc) {
+ if (global.mode & MODE_SYSTEMD)
+ waitpid(ret, NULL, 0);
exit(0); /* parent must leave */
+ }
/* if we're NOT in QUIET mode, we should now close the 3 first FDs to ensure
* that we can detach from the TTY. We MUST NOT do it in other cases since
C'est simplement tout pourris …
# systemd a bon dos
Posté par GeneralZod . Évalué à 8.
Extrait la page man de haproxy:
Évidemment, si HAProxy ne se comporte pas comme un daemon unix bien élevé, ça aide pas … Plutôt que faire une n-ième rustine, pourquoi ne pas corriger la conception défectueuse de HAProxy ?
[^] # Re: systemd a bon dos
Posté par Joris Dedieu (site web personnel) . Évalué à 10. Dernière modification le 08 novembre 2012 à 03:23.
Quelle conception défectueuse ? En quoi le fait d'envoyer des signaux à un process pour déclencher une action (ici s’arrêter proprement) poserait un problème. Comme tout daemon pouvant être chrooté, HAProxy est susceptible de ne pas pouvoir relire sa config. Un reload consiste donc à remplacer le process proprement par un autre en essayant de ne pas droper de clients au passage.
Un peu plus lin dans le man on a :
Bref, tu peux utiliser les signaux pour piloter ton daemon. Quel défaut de conception !
[^] # Re: systemd a bon dos
Posté par GeneralZod . Évalué à 6.
Merci, j'ai lu la même page man que toi.
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, et pas se saborder de manière ésotérique (en plus, y a des stratégies plus intelligentes que ça, Cf. Nginx)
Quand au chroot, c'est un faux argument, systemd n'a aucun problème avec les daemons chrootés correctement écrits, par exemple: Bind, Postfix, OpenSSH, Avahi, etc… idem quant aux daemons tournant dans un chroot.
[^] # Re: systemd a bon dos
Posté par Kaane . É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).
[^] # Re: systemd a bon dos
Posté par oinkoink_daotter . Évalué à 2.
Ben en fait, c'est plutôt un problème de l'init sys V qui ne sait pas faire de monitoring :-)
Hop le troll est bouclé. /o/ -->[]
Plus sérieusement, il faudrait peut-être regarder comment haproxy se gère sous Solaris avec SMF.
[^] # Re: systemd a bon dos
Posté par GeneralZod . Évalué à 3.
Je suis d'accord avec toi sur le fond (c'est la raison pour laquelle j'ai utilisé le verbe "senser" et non pas "devoir"). Le problème c'est que si tu ne normalises pas un minimum le comportement des daemons, ça devient rapidement le foutoir.
Le truc c'est que Nginx se débrouille pour se comporter comme un daemon unix "bien élevé".
Sans rien enlever à ses mérites, en tant que daemon unix il est mal architecturé, certes, il n'y a pas de normes à ce sujet mais il y a quand même un certains nombres de conventions qui sont globalement bien respectés depuis plusieurs décennies.
Si HAProxy se fout d'être un daemon unix correct, c'est leur problème, pas celui de l'init (ça doit être bien dégueulasse le script sysV pour le coup, parce que là, même avec les cgroups, on arrive à paumer le daemon en cours de route)
C'est un choix qui a été fait, pour éviter les abus et tout les hacks sales des init sysV.
Y a pleins de raisons pour critiquer systemd mais c'est très souvent les mauvaises qui sont invoqués (celle-là est pas mal dans le genre), et ça devient agaçant hors vendredi.
[^] # Re: systemd a bon dos
Posté par Kaane . Évalué à 3.
ça doit être bien dégueulasse le script sysV pour le coup, parce que là, même avec les cgroups, on arrive à paumer le daemon en cours de route
Euh non. Les scripts init pour haproxy font normalement tous un peu la même chose : quand on demande un reload, on se prend un restart.
C'est un choix qui a été fait, pour éviter les abus et tout les hacks sales des init sysV.
C'est bien pour ça que j'ai dit que ca n'est pas la faute de systemd non plus. Le choix de limiter le nombre de commandes dans systemctl ne me choque pas plus que ça. (Par contre l'absence de templates dignes de ce nom ou la impossibilité de faire des interactions utilisateurs pendant l'init me hérissent - mais c'est un autre débat).
[^] # Re: systemd a bon dos
Posté par Zenitram (site web personnel) . Évalué à 1.
Et ça ne te fait pas bizarre qu'un reload ne soit pas fait quand on demande un reload? Moi : si. Quand on demande un reload, on s'attend à un reload, sinon c'est juste que c'est mal conçu (cette partie, ça ne remet pas du tout en cause les qualités générales du soft) et c'est tout à fait légitime que systemd essaye de forcer les soft à être corrigés plutôt que de permettre des bidouilles.
Tu balances cette phrase comme si c'était normal… Bon, quand tu me demanderas d'aller à gauche, j'irai tout droit, et je m'offusquerai que tu t'offusqued que je n'ai pas fait ce que tu as demandé mais autre chose suivant mon envie.
Quand un admin demande un reload, il ne demande pas un restart et le soft ne doit pas faire un restart (sinon l'admin aurait demandé… un restart!)
(après, faudrait peut-être une réponse genre "reload: not supported")
[^] # Re: systemd a bon dos
Posté par Kaane . Évalué à 9.
Tu balances cette phrase comme si c'était normal
Ca l'est
Bon, quand tu me demanderas d'aller à gauche, j'irai tout droit
Ben dans ce cas tu ne fais pas ce que je t'ai demandé. Quand je demande un reload et qu'un serveur fait un restart il fait ce que je lui ai demandé (ie prendre en compte la nouvelle config). Si le concepteur du logiciel estime que pour prendre en compte la nouvelle config il faut nécessairement faire un restart, il est probable qu'il ait raison.
et c'est tout à fait légitime que systemd essaye de forcer les soft à être corrigés plutôt que de permettre des bidouilles.
Non.
Le truc c'est que le reload est déjà en lui même une bidouille - bien pratique certes, mais une bidouille. C'est même une bidouille assez récente en vrai et pas mal de versions un peu ancienne des logiciels ne supportent pas le reload et/ou l'interpretent comme un restart (On parle de trucs assez mainstream, genre apache 1 ou encore sendmail) et il y a encore pas mal de paramètres de pas mal de daemons qui nécessitent de toutes les façon un restart pour être prise en compte (un simple reload ne suffisant pas).
Pour signifier le reload on utilise une autre bidouille : envoyer à un daemon un signal qui n'a rien à voir avec la choucroute. Le SIGHUP sur un daemon c'est comme un poisson avec une bicyclette, si on est pas prévenu on voit pas vraiment ce que l'un et l'autre font ensemble.
Pour systemd c'est encore une bidouille de plus : si un daemon n'a pas d'interface DBus, alors on va lui envoyer un petit SIGHUP pour lui dire de recharger sa config. Donc je ne sais rien du daemon, on a pas d'interfaces pour dialoguer ensemble, mais je vais partir des principes suivants :
a) il a une fonction reload
b) cette fonction reload peut être déclenchée par un SIGHUP
c) Mon SIGHUP sera nécessairement pris en compte et le reload fonctionnera nécessairement (on a toujours pas d'interface pour dialoguer - donc si le serveur répond "pas maintenant" ou "j'ai pas les droits sur le fichier de config" on l'a dans l'os)
d) Ca ne génèrera pas de restart du daemon
e) Accessoirement quand on fait un reload de tel ou tel processus il n'y a pas de pre ou de post traitements à faire.
Bien entendu ca marche dans 99% des cas avec des daemons relativement modernes dans des paramétrages relativement standard - mais de là à dire que c'est de la lutte contre la bidouille (alors qu'il y en a déjà trois grosses pour mettre en place cette "lutte") et que systemd peut s'accorder le droit de faire comme il veut "pour le bien de tous", permet moi d'être circonspect.
Si les démons font la différence entre reload, reload_now et force_reload (avec toutes les variantes possibles et immaginables) c'est bien que SIGHUP à la barbare ne suffit pas, chercher à l'imposer comme LA référence est idiot. (Et ce n'est d'ailleurs pas le but de systemd - le hack du SIGHUP c'est plus un mode de compatibilité qu'autre chose.)
[^] # Re: systemd a bon dos
Posté par totof2000 . Évalué à 2.
Tiens, ça me fait le même effet quand sous Ubuntu je demande une installation d'OpenOffice et qu'il m'installe Libreoffice …
[^] # Re: systemd a bon dos
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
Ici par exemple la façon dont c'est géré sous FreeBSD. Personnellement, ça ne me semble pas monstrueux.
[^] # Re: systemd a bon dos
Posté par zebra3 . Évalué à -1. Dernière modification le 08 novembre 2012 à 14:25.
Ben pourtant quand j'ai demandé plus bas on m'a expliqué que ce n'est pas la même chose.
Edit: désolé, je n'avais pas lu tes explications en dessous.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd a bon dos
Posté par Joris Dedieu (site web personnel) . Évalué à 8.
En l'occurrence ça n'a pas d'objet ici. HAProxy, ne peut pas recharger sa config. Ce n'est pas un bug c'est un choix, pris en connaissance de cause. On peut toujours critiquer ce choix ou en discuter , mais je ne vois pas en quoi il concerne init.
Il faut comparer ce qui est comparable. HAProxy a un design a un seul process.
# systemd, c'est bien
Posté par Zenitram (site web personnel) . Évalué à 0.
Tu ne fais que démontrer que systemd est nécessaire, afin de forcer les daemons à être standard, que l'admin n'ai pas à souffrir de choix ésotériques quand il envoie une commande dont il attend un résultat prévu (qui fonctionne dans 99% des cas). Comme quoi, négatif ou positif, ça dépend pas mal du point de vue.
C'est rigolo de voir qu'on peut trouver vraiment n'importe quelle attaque bidon (en plus, même si ce n'était pas un problème ésotérique de haproxy, ho la la 10 lignes de code ne plus, la mort : ben non, on les code et on n'en parle plus sauf pour les râleurs qui ne codent pas mais veulent écrire un journal LinuxFr) pour pouvoir cracher sur le travail des autres.
[^] # Re: systemd, c'est bien
Posté par Moonz . Évalué à 10.
Bon, alors, si je suis bien ta position sur différents sujets, chez Microsoft ils sont sympa parce qu’ils font tout pour garder la rétrocompatibilité contrairement à ces hippies de Linuxiens qui s’en préoccupent pas, alors que chez systemd ils sont sympa parce qu’ils pètent la rétrocompatibilité ?
Ton boulot ce serait pas juste avocat du diable en fait ?
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 6.
Tu ne fais que démontrer que systemd est nécessaire, afin de forcer les daemons à être standard
Quitte à perdre au passage le proxy le plus performant disponible ?
Sans façon non.
Haproxy est un excellent proxy avec des perfs que ce soit en conso CPU ou en nombre de connexions par secondes qui sont inégalées.
Ceci est du à son architecture processus unique qui ne changera pas (et qui ne doit pas changer).
D'ailleurs la solution apportée est de créer un wrapper, pas de modifier le comportement de haproxy.
Donc non, il n'existe déjà pas de démons standards - et systemd ne va rien faire pour améliorer les choses.
[^] # Re: systemd, c'est bien
Posté par Zenitram (site web personnel) . Évalué à -2. Dernière modification le 08 novembre 2012 à 09:41.
J'aime bien : devoir adapter en faisant 10 lignes de code (et elles sont faites, tu ne perds absolument rien, on 'l'a déjà fait pour toi, comme des millions d'autres petites adaptations faites par des logiciels pour la compatibilité), c'est "perdre". C'est le concours de la plus grosse énormité qui est lancée par les opposants à systemd, faute d'argument qui tienne l'analyse? Le niveau est mis très haut de ce que je constate.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 2.
J'aime bien : devoir adapter en faisant 10 lignes de code (et elles sont faites, tu ne perds absolument rien, on 'l'a déjà fait pour toi, comme des millions d'autres petites adaptations faites par des logiciels pour la compatibilité),
Tu as mal lu. les dix petites lignes de codes ne sont pas là pour changer le comportement de Haproxy (qui est le bon), mais pour lui permettre d'être piloté par le wrapper systemd.
Donc le démon n'est pas normalisé, il continue à fonctionner exactement comme avant, mais il a maintenant une interface de plus pour être piloté un wrapper.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 8.
C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config qu'il est nécessaire de faire un wrapper pour ça et non de modifier ce comportement qui va détruire toute sa puissance… et après ça on doit en rire et y croire en buvant un bon café ?
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 7.
C'est quand même dingue qu'a vous lire, toute la puissance de haproxy réside dans son code de reload de config
Je réexplique pour les personnes un peu lente.
Toute la puissance d'haproxy vient du fait qu'il est à processus unique, piloté par évennement. (Single process, event driven).
Sur ce genre d'appli (un proxy en mode processus unique) il n'est pas possible de mettre à jour la config de façon dynamique. Il n'existe pas de méthode pour aglomérer intelligeament l'ancienne config et la nouvelle (les serveurs peuvent avoir changés d'ip ou de nom, certaines sessions autorisées peuvent être interdite, le poids de load balancing peut avoir été changé etc.)
A partir de la quand on modifie la config d'un proxy la seule bonne façon de faire est de tuer et de relancer les processus de proxification et de repartir à 0.
Si il y a un controlleur dédié (ie le daemon n'est pas le processus de proxification) alors le controlleur relance les processus fils un par un (c'est le cas pour nginx) mais dans le cas d'une appli à processus unique la SEULE façon de faire est de relancer complètement le processus.
A partir de là forcément il faut créer un "pseudo controlleur" pour devenir compatible avec systemd. Le "pseudo controlleur" ne fera rien d'autre que de lancer haproxy et de lui passer les messages systemes (d'ou le "pseudo").
Donc en fait : proxy+architecture à processus unique = on relance tout en cas de changement de config.
Le pseudo controlleur ne sert à rien d'autre qu'à faire plaisir à systemd d'ou le terme de wrapper.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 1.
je vois pas pourquoi, c'est un choix de design, je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit. Et le problème n'est pas là, vu que 1* il y a un déjà un wrapper, 2* celui-ci agit mal 3* le patch proposé contient des if (systemd) ce qui semble absurde.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 9.
je vois pas pourquoi, c'est un choix de design
Tu peux en discuter avec le mec d'haproxy si tu veux, son design single process est actuellement le proxy le plus rapide disponible pour un cout CPU ridicule.
je vois pas ce que processus unique ou non, que ce soit un proxy ou un lecteur audio ou un livre de schtroumph y change quoi que ce soit
Une appli standard a tout intéret à conserver son état interne quelque part et à disposer en permanence de tous les éléments pour comprendre et analyser cet état.
Un proxy n'a aucun intéret à faire celà, il doit faire de la mise en relation le plus rapidement possible entre des clients et des serveurs. A partir de la une question comme "comment on en est arrivé là" ne l'interresse pas. Pour être capable de recharger dynamiquement une config un proxy devrait être capable de comprendre pour quel raison il est dans l'état présent, de réinterpréter l'état en fonction de la nouvelle config et de notifier de façon transparente le client et le serveur des décisions qu'il a prise. Sur un proxy générique comme haproxy c'est tout simplement impossible (ne serait-ce que de convaincre un autre serveur http de reprendre une session modifiée comme si c'était une des siennes ca va être coton, à moins d'en avoir rien à faire de la sécurité du bigniou).
Donc un proxy raisonnablement générique n'a pas vraiment d'autre choix que de redémarrer à chaque changement de config. Et si on doit redémarrer ET que l'on est en architecture processus unique ben paf le systemd.
Pas encore il est en cours d'écriture
Vu le chemin choisi, il n'agira pas plus mal qu'un controlleur NGINX
Pas plus absurde qu'autre chose. Sur un init classique je n'ai pas besoin de l'overhead lié à systemd - donc autant s'en passer. Surtout que généralement quand on utilise haproxy c'est que l'on veut utiliser jusqu'à la dernière goutte de CPU disponible pour créer des connexions. Personellement je serais même pour un configure --without-systemd (ce qui j'imagine dans ta vision serait encore pire).
[^] # Re: systemd, c'est bien
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Par ailleurs un changement de config n'est nécessaire que lorsque ta topologie est modifiée. Pour les opérations courantes comme les maintenances de serveur, tu disposes d'une socket de contrôle te permettant de les réaliser à chaud.
[^] # Re: systemd, c'est bien
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 08 novembre 2012 à 10:56.
A moins que… Ca soit un autre problème que les "personnes" autres que toi (bref, c'est peut-être toi).
- if (arg_mode & MODE_DAEMON) {
+ if (arg_mode & (MODE_DAEMON | MODE_SYSTEMD)) {
Faut que tu m'explique en quoi ça ne ferait plaisir qu'à systemd (et personne d'autre), dans le patch proposé je ne vois rien qui est un ajout, juste un test en plus pour activer du code qui existe déjà.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 6.
Tu as encore mal lu (décidément c'est récurrent), il prépare le terrain pour du code qui n'existe pas encore :
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 4.
Si c'est le cas, alors il ne devrait pas avoir a différencier un mode daemon et un mode systemd… il suffit de faire correctement le wrapper et il sera générique (voir de modifier haproxy pour au choix, qu'il puisse reloader sa config dynamiquement sans se tuer/relancer, soit qu'il y ai intégré un processus de control qui s'occupe de faire ça… le fameux wrapper), mais je ne vois aucune raison logique de prendre en compte spécifiquement systemd, les autres daemons n'en ont pas besoin, preuve que c'est non-nécessaire.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 3.
il suffit de faire correctement le wrapper et il sera générique
On peut effectivement faire un controlleur "light" plutôt qu'un wrapper spécifique à systemd.
Sauf que je ne vois pas pourquoi j'irais perdre des perfs avec un controlleur, alors que je cherche au contraire à en gagner le plus possible.
Problème systemd => Verrue systemd.
les autres daemons n'en ont pas besoin, preuve que c'est non-nécessaire
Tout à fait, et d'ailleurs les autres démons n'ont pas besoin de 99% de ce qu'utilise un démon pris au hasard. Preuve que les démons c'est non nécessaire.
Ou alors c'est juste qu'il y a très peu de démons en mode single processus pour qui un reload dynamique est hors de question.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 6.
Arrête de me faire rire… le controlleur il est juste là à attendre des signaux… il n'a aucun impact sur la perf du process qui est controllé.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 3.
Arrête de me faire rire… le controlleur il est juste là à attendre des signaux… il n'a aucun impact sur la perf du process qui est controllé.
Il y a pas que SIGHUP dans la vie.
Les autres signaux m'interressent peut être, et peut-être que le fait de les recevoir quelques microsecondes plus tôt et sans context switch m'interresse.
Ensuite même si il ne fait que d'écouter les signaux et les rebalancer il me prend quand même de la mémoire, du CPU etc. Alors qu'il ne me sert à rien si je n'ai pas systemd.
[^] # Re: systemd, c'est bien
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Mauvaise raison : des processus qui ne sollicitent exactement que ce dont ils ont besoin en mémoire/CPU, ça n'existe pas. Il y a quand même des limites à ne pas dépasser, mais lorsque je te vois critiquer un process de contrôle pour des raisons de performances, je trouve ça quand même assez cocasse :)
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 5.
mais lorsque je te vois critiquer un process de contrôle pour des raisons de performances, je trouve ça quand même assez cocasse :)
Ben écoute tu le prends comme tu veux. On va juste dire que l'auteur du logiciel haproxy refuse les controlleurs pour des raisons de performances - et accessoirement il a le proxy TCP le plus rapide et le plus léger que je connaisse. Peut-être qu'il se trompe et qu'un controlleur n'aurait pas d'impact sur les perfs, en attendant et depuis dix ans, c'est lui qui tiens la position de tête au niveau proxy. Donc tout bien pris en compte, il semblerait que son choix ne soit pas idiot.
[^] # Re: systemd, c'est bien
Posté par groumly . Évalué à -3.
Bon, gros malin, tu vas aller me deployer un HAProxy, le charger ras la gueule jusqu'a saturer ton lien gigabit.
Ensuite, tu vas prendre la version modifier, et tu vas faire la meme chose.
Et quand t'auras fait tout ca, tu reviens ici avec tes benchmark.
Je serais très surpris que tu sois capable de dire, en aveugle, quelles perfs correspondent a quelle version d'HAProxy.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 2.
a) Avec HAProxy ce sont plutot des liens 10Gb que je sature, généralement par paquet de quatre (sinon les fusion I/O se sentent inutiles)
b) Il existe déjà un excellent proxy sur-optimisé avec un controlleur très très light pour le HTTP : NGINX. Et ben tu sais quoi, il se fait battre par HAProxy au niveau perfs pures (d'un autre coté aussi il fait beaucoup plus de choses que HAProxy - et en plus on peut assez facilement les combiner c'est du bonheur)
c) Le wrapper n'existe pas encore - donc pour les benchs il va falloir attendre.
d) Parmis les benchs des trucs qui m'intéressement il y a le temps que met HAProxy à redémarrer et pour quel cout CPU - Sur cet partie du bench je peux te garantir que je pourrais faire la différence à 100% entre les deux versions même si les temps de respawn sont rigoureusement identiques. Ne serait-ce qu'en surveillant les context swap.
[^] # Re: systemd, c'est bien
Posté par zebra3 . Évalué à 6.
Dans ce cas il y a un truc que je ne pige pas : c'est quoi la différence entre un reload et un restart ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 6.
Permettre de troller sur dlfp \o/
[^] # Re: systemd, c'est bien
Posté par Joris Dedieu (site web personnel) . Évalué à 7.
Un reload :
- lancer un nouveau processus
- si failed ne rien faire
- dire à l'ancien de ne plus écouter sur le réseau (les nouveaux clients vont sur le nouveau processus)
- dire à l'ancien de mourrir quand il a fini avec ses clients
Un restart :
- tuer l'ancien processus
- en lancer un nouveau
[^] # Re: systemd, c'est bien
Posté par zebra3 . Évalué à 5.
Merci c'est plus clair.
Faut quand même reconnaître que c'est pas un comportement très répandu et ça ne me paraît pas très clean (les anciens clients restent avec l'ancienne config).
M'enfin il faudrait avoir l'avis de Lennart, c'est peut-être possible d'en implémenter la prise en charge dans systemd.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd, c'est bien
Posté par Joris Dedieu (site web personnel) . Évalué à 3.
Le temps de finir leur connexion, oui. Pour moi c'est essentiel. Sinon ils se retrouvent avec un "connexion réinitialisé" dans leur navigateur. Ça fait pas très propre. C'est également ce que fait apache quand tu fais un graceful. Le fils ne meure que quand il a fini les requêtes en cours.
Par ailleurs, il est également possible de demander de terminer les sessions immédiatement tout en gardant la sécurité de savoir que le nouveau processus est prêt avant de tuer l'ancien.
[^] # Re: systemd, c'est bien
Posté par Gof (site web personnel) . Évalué à 6.
Difficile peut être, mais impossible, non.
Il suffit, lors du changement de config, d'aller changer les structures de données, fermer les connections qui ne sont plus autorisées, etc.
C'est juste une question de paresse.
Un peu comme certaines applications graphiques doivent redémarrer quand on change de langue, et d'autres pas (de moins en moins). Car il est vrai que ça demande un travail considérable de vider les bons caches, d'aller modifier les bonnes structures de données, de considérer que certaines valeur que l'on pourrait croire constantes peuvent changer.
Et la paresse est tout à fait justifiée puisque ça permet de se concentrer sur des fonctionnalités plus utiles que un changement dynamique de config.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 2.
Je suis bien d'accord avec ça, mais faut pas pousser bobonne en affirmant que c'est je cite "une architecture à processus unique blabla proxy blabla qui fait que blabla pas possible tu comprends … culé le mouton.".
Pour haproxy, je peux parfaitement comprendre le wrapper, mais pas que ce wrapper soit designé spécifiquement autour d'une utilisation par systemd… alors que la majorité des daemons n'ont aucun problème avec systemd… Donc du coup si c'est pour écrire un wrapper autant qu'il soit générique (ou alors faut m'expliquer en quoi ce wrapper doit absolument savoir qu'il est lancé via systemd…).
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 3.
Comment tu transfères une session sécurisée ?
Comment tu fais la différence entre un nouveau serveur et un serveur qui a juste changé d'IP
Comment tu prend en compte le load-balancing/le session queuing/les flags TCP ?
Comment tu réadresse tes lans/vlans ?
Comment tu notifies les clients et les serveurs de tes décisions ?
etc.
On est pas juste dans le domaine de la paresse, il faudrait uen norme complète de prise en charge des modifications de topologie aussi bien au niveau client que serveur, et un proxy avec des tables de suivi de cent pieds de long. Grosso modo ca revient à transformer le proxy en firewall/router coeur de réseau. C'est un poil overkill pour la plupart des applications non ?
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 2.
En quoi c'est lié à tuer le process ou non ?
Ici le cas c'est, je lance un nouveau process avec nouvelle config, j'attend que le vieux process arrête son travail en cours proprement et s'arrête, je prends la main… je vois pas ce qui empêche de faire ça dans un seul process sans le tuer…
C'est juste que haproxy a décidé de faire comme ça… ça fait du code en moins pour un cas anecdotique et je le conçois bien, mais c'est juste ça, pas un fondamental d'architecture.
[^] # Re: systemd, c'est bien
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Le fait que ce process soit chrooté.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 1.
Tu veux dire ? que non seulement on change sa config et qu'on le chroot alors qu'il ne l'était pas ?
Sinon je vois pas, si il est chrooté, sa config l'est aussi non ? Et si elle ne l'est pas, c'est pas juste un changement de config… et un graceful stop + start, j'ai dû mal à appeler ça un reload et à associer ça à la même fonctionnalité.
Soit c'est un du reload de config, soit ça ne l'est pas, mais assimiler graceful stop + start, c'est pas (juste) du reload de config et ne devrait pas être utiliser comme tel.
[^] # Re: systemd, c'est bien
Posté par Joris Dedieu (site web personnel) . Évalué à 3. Dernière modification le 08 novembre 2012 à 12:26.
Bien sûr que non. Il se chroote dans un répertoire vide (typiquement /var/empty). Donc il ne peut pas relire sa config.
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 2.
Donc cf: le reste de la phrase.
Et autre trucs… comment font les autres daemon dans ce cas sous systemd ? Je doute fort qu'ils se crashent comme des veaux dans l'état failed.
Donc si un process est chrooté et n'a donc plus d'accès à sa config… je vois pas comment on peut qualifier ça de reload.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 4.
Ici le cas c'est, je lance un nouveau process avec nouvelle config, j'attend que le vieux process arrête son travail en cours proprement et s'arrête
Sauf que ton nouveau process ne pourra pas être actif tant que l'ancien n'est pas arrété (sinon bonjour le mic-mac au niveau des sessions) et que donc tu vas perdre des connexions. Si il y a un mec qui a décidé de télécharger un projet de plusieurs Go, tu es juste bloqué pendant des heures sans pouvoir accepter de connexions.
Ou alors tu essayes de finir les sessions actives pendant un temps raisonnables (on va dire 10 secondes) mais sur un site à forte demande ca n'est pas top non plus. Et en plus tu finis quand même par fermer tout brutalement et te relancer si toutes les sessions ne sont pas closes au bout de 10sec.
La meilleure solution (en fait la seule qui soit viable) consiste à tout foutre par terre et à laisser les serveurs se démerder si ils veulent de la résistance/de la reprise de session logique. C'est d'ailleurs la solution adoptée par tout le monde (NGINX, apache mod_proxy, squid etc.)
[^] # Re: systemd, c'est bien
Posté par allcolor (site web personnel) . Évalué à 2.
Ok bardaf c'est l'embardée… en gros on fait un restart quoi, donc on se nouille pour rien.
[^] # Re: systemd, c'est bien
Posté par Thomas Douillard . Évalué à 3.
Il suffit pas tout simplement de binder une connextion avec une config en lecture seule et de binder les nouvelles connexions avec la nouvelle config ? Voila tu as évité ton effet de bord diabolique.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 3.
Il suffit pas tout simplement de binder une connextion avec une config en lecture seule et de binder les nouvelles connexions avec la nouvelle config ? Voila tu as évité ton effet de bord diabolique.
Le problèmes est que tu ne peux pas faire la différence entre la continuation d'une ancienne connexion et une nouvelle connexion "simplement".
Prend le FTP pasif comme exemple. Ou une connexion avec un tunnel. Autant tu peux suivre la connexion "au fil de l'eau" autant quand tu vas changer ton proxy (ce qui veut dire que tu vas avoir un autre processus qui va se mettre à écouter sur une plage de port) tu vas te retrouver comme un con en voyant arriver les demandes. Tu as besoin des infos qui sont dans l'ancienne appli pour t'assurer que la connexion sur le port X est nouvelle ou ancienne, connue ou inconnue. Et ca serait très pénalisant au niveau perf de faire ça.
[^] # Re: systemd, c'est bien
Posté par Thomas Douillard . Évalué à 2.
très pénalisant de garder un pointeur vers la config pour chaque socket d'ouverte ? ça ajoute au pire une indirection de pointeurs quand tu veux accéder aux infos.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 4.
très pénalisant de garder un pointeur vers la config pour chaque socket d'ouverte ? ça ajoute au pire une indirection de pointeurs quand tu veux accéder aux infos.
Sur un logiciel dont le but est d'ouvrir des centaines de milliers de connexions par seconde - oui c'est pénalisant.
Ensuite il ne suffit pas d'avoir la config du socket coté proxyC ou proxyS , mais assez de metas données pour pouvoir "deviner" que la connexion sur le port TCP 12312 est une session FTP passif et que donc lorsque je vais recevoir une demande d'ouverture de port sur le 12313 par le même client, il va falloir que je l'accepte et que je le redirige vers le bon serveur en cas d'authentification etc.
Tout ceci n'est pas le boulot d'un proxy TCP. C'est éventuellement le boulot d'un routeur/firewall coeur de réseau.
[^] # Re: systemd, c'est bien
Posté par Kaane . Évalué à 8.
Oups toute mes excuses allcolor, j'avais mon canon à Zenitram chargé et le coup est parti tout seul.
Faut dire que ton imitation était troublante.
Donc je retire le coté incisif et le qualificatif "personne un peu lente" de ma réponse précédente. Toutes mes excuses.
(Mai aussi… Faite gaffe les mecs avec les appeaux à trolls quand vous portez pas de gilet orange…)
[^] # Re: systemd, c'est bien
Posté par barmic . Évalué à 4.
De ce que je comprends. Haproxy n'a qu'un seul processus, pour recharger sa conf il se relance. Systemd gère pas ce genre de cas. Le gérer d'une autre manière implique d'avoir plusieurs processus ce qui nuirait aux performances.
Personnellement je trouve ne sais pas si comme tu le dis en dessous c'est un bug, mais c'est dommage d'avoir si peu de flexibilité. J'aime bien systemd et je trouve qu'il apporte un tas de choses bien mais là ça va être moyen pour les binaires propriétaires qui ont un comportement pas classique. Il va falloir créer des wrappers qui vont rester en mémoire et tenter de faire coïncider leur état propre avec ce que veux systemd. Mais bon ça va pas non plus changer le monde.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd, c'est bien
Posté par jigso . Évalué à 1.
Je plussoie, et je trouve même que systemd ne vas pas assez loin ; il aurait dû imposer une interface complète pour les services, comme par ex celle-là
Au moins c'est clair, net et standard. Et zou, y'apuka porter les daemons existants - suffit juste de bouger quelques lignes hein, c'est pas la mort, fonctionnellement rien ne change…
[^] # Re: systemd, c'est bien
Posté par Kerro . Évalué à 3.
Même en imaginant une API correcte, cela n'empêche pas d'avoir du code mal écrit.
Il y a un paquet de services Windows qui ne s'arrêtent pas correctement avec un "net stop xxxx" pour des prétextes bidons. Il faut un bon gros pskill des familles. Alors que l'API est simple (et très incomplète, ça a peut-être changé avec les versions récentes).
[^] # Re: systemd, c'est bien
Posté par jigso . Évalué à 1.
(ah zut, j'avais oublié les balises <ironie></ironie> )
[^] # Re: systemd, c'est bien
Posté par Kerro . Évalué à 2.
On a pigé que c'est du second degré. Cela n'empêche pas de répondre quelque chose de sensé.
# La pourriture
Posté par allcolor (site web personnel) . Évalué à 4.
Ce qui est pourris c'est de modifier pour prendre en compte spécifiquement systemd au lieu de corriger l'implémentation défectueuse de la gestion de rechargement de config.
Le problème il est pas dans systemd mais chez le programmeur qui préfère rajouter des if (systemd) plutôt que de corriger ce qu'on peut sans problème qualifier de bug.
# Pardonnez ma question
Posté par MTux . Évalué à 7.
Mais n'étant pas développeur, j'ai rien compris.
[^] # Re: Pardonnez ma question
Posté par Beurt . Évalué à 6.
Et quelle est la question qu'on doit te pardonner ?
[^] # Re: Pardonnez ma question
Posté par MTux . Évalué à 4.
Que doit-on déduire après lecture du code exposé dans cet article ?
[^] # Re: Pardonnez ma question
Posté par Anthony Jaguenaud . Évalué à 7.
Hadproxy a fait un choix d’architecture lui permettant d’être performant… Mais en cas de reload de la config, il fait le choix de se tuer et de se relancer.
Systemd a fait le choix de considérer que le « fair-use » autour du signal SIGHUP (utilisé pour recharger la conf par beaucoup) était standard et l’applique.
Du coup, il faut faire un enrobage pour que hadproxy et systemd bosse ensemble.
En gros, systemd impose la façon dont Lennart croit qu’il faut écrire un démon.
[^] # Re: Pardonnez ma question
Posté par zebra3 . Évalué à 5.
J'ai plutôt l'impression qu'il reprend un standard de fait.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pardonnez ma question
Posté par Anthony Jaguenaud . Évalué à 3.
Oui, c’est ce que je dis en parlant de « fair-use » que tu as très bien écris en français : « standard de fait », mais tu ne retiens que le troll…
Pour répondre quand même, oui c’est un standard de fait mais ce n’est pas la seule façon de faire, et là on touche au problème que le système d’init impose une façon de faire ce que je trouve gênant, intrusif et abusif.
[^] # Re: Pardonnez ma question
Posté par Zenitram (site web personnel) . Évalué à -7.
Oauis, fait chier la langue commune, parlons tous une langue différente, c'est tellement plus marrant pour communiquer.
Le but n'est-il pas d'avoir une communication?
Qu'est-ce qui est gênant?
Qu'est-ce qui est intrusif?
Qu'est-ce qui est abusif?
Rien. C'est du pur fantasme mégalomaniaque, rien de plus. On en revient à la résistance au changement, en inventant 36 problèmes inexistants, encore et toujours…
[^] # Re: Pardonnez ma question
Posté par Anthony Jaguenaud . Évalué à 2.
Merci d’intervenir dans une discussion cordiale avec un ton pareil… c’est peut-être plus marrant pour communiquer, mais je te laisserai continuer ta discussion avec ta véhémence seul.
À+
[^] # Re: Pardonnez ma question
Posté par Zenitram (site web personnel) . Évalué à -7. Dernière modification le 08 novembre 2012 à 11:05.
"impose (…) gênant, intrusif et abusif" sans absolument aucune argumentation, c'est juste du FUD, désolé j'ai du mal à voir du cordial dans du FUD. Ma réaction est juste à la hauteur de la non cordialité du message auquel j'ai répondu.
[^] # Re: Pardonnez ma question
Posté par zebra3 . Évalué à 3.
Désolé, je ne comprenais pas le sens de fair-use dans ce cadre (c'est un terme plutôt juridique).
Reste que l'un des buts de systemd est de simplifier la vie des administrateurs, donc je ne suis pas choqué s'il simplifie pour réduire au plus petit dénominateur commun (par exemple, pour standardiser les fichiers .services).
Après, je ne sais pas si c'est un choix délibéré de Lennart de ne supporter qu'une méthode, ou si c'est juste que ça n'a pas posé de problème jusque là, auquel cas il sera peut-être possible de modifier son comportement.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pardonnez ma question
Posté par Anthony Jaguenaud . Évalué à 5.
Oui, mais je suis nul en français, même si je m’améliore. Je cherchais un terme signifiant « façon de faire couramment admise » ou quelque chose d’approchant.
Ce n’est pas un problème de Lennart, ceci était mon troll, mais un problème que l’init impose une architecture logiciel à un démon.
L’auteur de ce dernier à fait un choix qui permet certainement de simplifier le code en interne, moins de tests, moins de communication inter thread/process, et les performances augmentent. C’est un peu comme si de programme de login graphique (dm) imposait une architecture au gestionnaire de fenêtre (wm). Je trouve cela intrusif. Ce n’est que mon avis.
Le gras est pour Zenitran ;-p
[^] # Re: Pardonnez ma question
Posté par Philip Marlowe . Évalué à 4.
Si tout le monde fait comme ça son tour de taille risque d'exploser…
[^] # Re: Pardonnez ma question
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
Systemd ne comprend pas HAProxy qui à une façon particulière de se recharger. On ne parle pas de redemarrer - stop puis start - mais de se recharger de façon transparente pour les clients.
Un gars à proposé un patch qui consiste à conserver un processus qui ne fait rien d'autre qu'attendre que haproxy termine. Cela permet de berner systemd.
[^] # Re: Pardonnez ma question
Posté par MCMic (site web personnel) . Évalué à 2.
Bon, avec tous les commentaires je commence un peu à comprendre l'histoire (si le journal avait pu directement contenir des informations suffisantes ça aurait été mieux).
Mais ce que je n'ai toujours pas compris: En quoi le comportement de haproxy pose problème avec systemd? À ce que j'ai compris systemd demande un reload, et haproxy relance le processus parce que ça correspond à son reload, comment systemd s'en rend-t-il compte et en quoi cela le gène-t-il? Lui il envoie juste l'ordre non?
[^] # Re: Pardonnez ma question
Posté par Anthony Jaguenaud . Évalué à 3.
En fait, haproxy s’exécute sous un pid (process id) P. il se duplique, on obtient donc deux pid P et F. F, le nouveau dit le fils se ré-exécute lui même. Lorsque l’ancien P a fini, il se tue. Comme systemd ne connait que P, il dit que le démon est mort et affiche le service à failed. Alors que F fonctionne et est toujours fonctionnel.
Voilà ce que j’en ai compris.
# Précision
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
J'ai oublié de précisé tellement j'étais mort de rire que ce patch n'est pas de l'auteur. Il s'agit d'une contribution qui pour l'heure n'est pas commitée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.