# 4. Arrêt et redémarrage de HAProxy > Signaux, arrêts doux, rechargements et redémarrages en mode maître-worker --- Index LLMS : [llms.txt](/fr/llms.txt) --- HAProxy prend en charge une interruption douce et une interruption brutale. L'interruption brutale est simple : lorsqu'un signal SIGTERM est envoyé au processus HAProxy, celui-ci quitte immédiatement et toutes les connexions établies sont fermées. L'interruption douce est déclenchée lorsqu'un signal SIGUSR1 est envoyé au processus HAProxy. Elle consiste à ne plus se lier aux ports d'écoute, tout en continuant à traiter les connexions existantes jusqu'à leur fermeture. Une fois la dernière connexion fermée, le processus se termine. La méthode d'arrêt rigide est utilisée pour les actions « stop » ou « restart » du script de gestion du service. L'arrêt graduel est utilisé pour l'action « reload », qui tente de recharger en douceur une nouvelle configuration dans un nouveau processus. Ces signaux peuvent être envoyés par le nouveau processus HAProxy lui-même pendant un rechargement ou un redémarrage, afin de ne les émettre qu'au dernier moment et seulement s'ils sont indispensables. C'est ce que font respectivement les options "-st" (arrêt brutal) et "-sf" (arrêt gracieux). En mode master-worker, il n'est pas nécessaire de lancer un nouveau processus haproxy pour recharger la configuration. Le processus master réagit au signal SIGUSR2 en s'exécutant à nouveau avec le paramètre -sf suivi des PID des workers. Le master analysera alors le fichier de configuration et créera de nouveaux workers. Pour mieux comprendre l'utilisation de ces signaux, il est essentiel de maîtriser l'ensemble du mécanisme de redémarrage. Tout d’abord, un processus HAProxy existant est en cours d’exécution. L’administrateur utilise une commande spécifique au système, telle que « /etc/init.d/haproxy reload », pour indiquer qu’il souhaite appliquer le nouveau fichier de configuration. Ce qui se produit ensuite est le suivant. Tout d’abord, le script de service (/etc/init.d/haproxy ou équivalent) vérifiera que le fichier de configuration est correctement parsé à l’aide de la commande « HAProxy -c ». Ensuite, il tentera de démarrer HAProxy avec ce fichier de configuration, en utilisant « -st » ou « -sf ». Ensuite, HAProxy tente de se lier à tous les ports d'écoute. Si des erreurs critiques se produisent (par exemple : adresse non présente sur le système, accès refusé), le processus se termine avec une erreur. Si la liaison d'une socket échoue car un port est déjà utilisé, le processus envoie d'abord un signal SIGTTOU à tous les PID spécifiés dans la liste de PID "-st" ou "-sf". Ce signal est appelé le « signal de pause ». Il invite tous les processus haproxy existants à interrompre temporairement l'écoute de leurs ports afin que le nouveau processus puisse réessayer la liaison. Pendant cette période, le processus ancien continue à traiter les connexions existantes. Si la liaison échoue toujours (par exemple parce qu'un port est partagé avec un autre démon), le nouveau processus envoie un signal SIGTTIN aux anciens processus pour leur demander de reprendre leurs opérations comme si rien ne s'était produit. Les anciens processus reprennent alors l'écoute des ports et continuent à accepter les connexions. Notez que ce mécanisme dépend du système et que certains systèmes d'exploitation ne le supportent pas en mode multi-processus. Si le nouveau processus parvient à se lier correctement à tous les ports, il envoie soit le SIGTERM (arrêt forcé en cas de "-st"), soit le SIGUSR1 (arrêt graduel en cas de "-sf") à tous les processus pour leur notifier qu’il est désormais chargé des opérations et que les anciens processus doivent quitter, soit immédiatement, soit une fois leur tâche terminée. Il est important de noter qu’au cours de cette période, deux courtes fenêtres de quelques millisecondes chacune peuvent entraîner une légère augmentation du nombre de défaillances de connexion, notamment sous forte charge. Les taux de défaillance observés sont généralement d’environ 1 défaillance par rechargement pour chaque 10 000 nouvelles connexions par seconde, ce qui signifie qu’un site fortement sollicité fonctionnant à 30 000 nouvelles connexions par seconde peut connaître environ 3 défaillances de connexion à chaque rechargement. Ces deux situations se produisent lorsque : - si le nouveau processus échoue à se lier en raison de la présence du processus ancien, il devra d'abord passer par la séquence SIGTTOU+SIGTTIN, qui dure généralement environ un milliseconde pour quelques dizaines de frontaux, pendant laquelle certaines ports ne seront ni liés au processus ancien ni encore liés au nouveau. HAProxy contourne ce problème sur les systèmes qui prennent en charge les options de socket SO_REUSEPORT, car elles permettent au nouveau processus de se lier sans devoir d'abord demander au processus ancien de se délier. La plupart des systèmes BSD ont pris en charge cela depuis longtemps. Linux l'a pris en charge à partir de la version 2.0, puis l'a supprimé vers la version 2.2, bien que des correctifs aient été disponibles à l'époque. Il a été réintroduit dans le noyau 3.9 ; si vous constatez un taux d'échec de connexion supérieur à celui mentionné ci-dessus, veillez à ce que votre noyau soit la version 3.9 ou ultérieure, ou que les correctifs pertinents aient été appliqués à votre noyau (moins probable). - lorsque les anciens processus ferment les ports d'écoute, le noyau ne redistribue pas toujours les connexions en attente restantes dans la file d'attente du socket. En cas de charge élevée, un paquet SYN peut survenir juste avant la fermeture du socket, ce qui entraîne l'envoi d'un paquet RST au client. Dans certains environnements critiques où même une seule perte est inacceptable, ces pertes sont parfois gérées à l'aide de règles de pare-feu bloquant les paquets SYN pendant le redémarrage, forçant ainsi le client à réessayer. Cette solution dépend entièrement du système, car certains systèmes peuvent accéder à d'autres files d'attente d'écoute et éviter ainsi ce RST. Un deuxième cas concerne l'ACK du client sur un socket local qui était en état SYN_RECV juste avant la fermeture. Cet ACK entraîne l'envoi d'un paquet RST alors que le processus haproxy n'est pas encore au courant. Ce cas est plus difficile à éliminer, bien que les règles de filtrage du pare-feu mentionnées ci-dessus fonctionnent bien si elles sont appliquées une seconde environ avant le redémarrage du processus. Pour la grande majorité des utilisateurs, de tels écarts ne se produiront jamais, car ils n'ont pas une charge suffisante pour déclencher les conditions de concurrence. Et pour la plupart des utilisateurs à fort trafic, le taux d'échec reste encore raisonnablement dans la marge de bruit, à condition qu’au moins SO_REUSEPORT soit correctement pris en charge sur leurs systèmes.