Rechargement HAProxy - les anciens processus ne sont jamais terminés

J'ai la configuration HAProxy en mode TCP, avec un délai d'expiration client / serveur / connexion de 120 s.

Lorsque je recharge la configuration trop rapidement, je me retrouve parfois avec plusieurs processus. Par conception, cela est prévu, donc toutes les connexions établies sont vidées.

Mon problème est qu'ils n'ont jamais été interrompus, même si toutes les connexions sont fermées.

ps aux | haproxy

    haproxy  12483  0.0  0.1 103748  1084 ?        Ss   20:45   0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf 12405
    haproxy  12485  0.0  0.1 103748  1088 ?        Ss   20:45   0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf 12405
    haproxy  12487  0.0  0.1 103748  1084 ?        Ss   20:45   0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf 12405
    haproxy  25115  0.0  0.1 103748  1084 ?        Ss   21:26   0:00 /usr/sbin/haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf 12488

netstat -pant | grep haproxy

tcp        0      0 0.0.0.0:443                 0.0.0.0:*                   LISTEN      25115/haproxy
    tcp        0      0 0.0.0.0:1936                0.0.0.0:*                   LISTEN      25115/haproxy
    tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      25115/haproxy

J'ai attendu plus longtemps que le délai de 120 secondes. Je ne comprends pas ce qui les retient.

Le lsof suivant pour l'un de ces anciens processus montre qu'il existe encore des FD pour TCP LISTEN

# lsof -p 12483
COMMAND   PID    USER   FD   TYPE  DEVICE SIZE/OFF   NODE NAME
haproxy 12483 haproxy  cwd    DIR   202,1     4096      2 /
haproxy 12483 haproxy  rtd    DIR   202,1     4096      2 /
haproxy 12483 haproxy  txt    REG   202,1  4381869 412355 /usr/local/sbin/haproxy
haproxy 12483 haproxy  mem    REG   202,1    62864 396140 /lib64/libnss_files-2.17.so
haproxy 12483 haproxy  mem    REG   202,1   126288 396526 /usr/lib64/libselinux.so.1
haproxy 12483 haproxy  mem    REG   202,1   141760 396148 /lib64/libpthread-2.17.so
haproxy 12483 haproxy  mem    REG   202,1    89312 396076 /lib64/libgcc_s-4.8.2-20140120.so.1
haproxy 12483 haproxy  mem    REG   202,1    98720 396150 /lib64/libresolv-2.17.so
haproxy 12483 haproxy  mem    REG   202,1    13224 396957 /lib64/libkeyutils.so.1.5
haproxy 12483 haproxy  mem    REG   202,1    43768 396966 /lib64/libkrb5support.so.0.1
haproxy 12483 haproxy  mem    REG   202,1    19512 396128 /lib64/libdl-2.17.so
haproxy 12483 haproxy  mem    REG   202,1   170784 396962 /lib64/libk5crypto.so.3.1
haproxy 12483 haproxy  mem    REG   202,1    12744 396594 /usr/lib64/libcom_err.so.2.1
haproxy 12483 haproxy  mem    REG   202,1   937952 396964 /lib64/libkrb5.so.3.3
haproxy 12483 haproxy  mem    REG   202,1   273672 396958 /lib64/libgssapi_krb5.so.2.2
haproxy 12483 haproxy  mem    REG   202,1   486512 396073 /lib64/libfreebl3.so
haproxy 12483 haproxy  mem    REG   202,1  2000552 396122 /lib64/libc-2.17.so
haproxy 12483 haproxy  mem    REG   202,1  1967496 400756 /lib64/libcrypto.so.1.0.1j
haproxy 12483 haproxy  mem    REG   202,1   445424 400761 /usr/lib64/libssl.so.1.0.1j
haproxy 12483 haproxy  mem    REG   202,1    88568 396529 /lib64/libz.so.1.2.7
haproxy 12483 haproxy  mem    REG   202,1    36856 396126 /lib64/libcrypt-2.17.so
haproxy 12483 haproxy  mem    REG   202,1   152376 396115 /lib64/ld-2.17.so
haproxy 12483 haproxy    0u  0000     0,9        0   5420 anon_inode
haproxy 12483 haproxy    4u  IPv4 1435667      0t0    TCP *:http (LISTEN)
haproxy 12483 haproxy    5u  IPv4 1435668      0t0    TCP *:https (LISTEN)
haproxy 12483 haproxy    6u  IPv4 1435673      0t0    TCP *:jetcmeserver (LISTEN)

haproxy

— Bastien974
source

Hmm, donc l'ancien processus possède toujours l'auditeur auquel il ressemble? Qu'est-ce qui remplit le -sfdans votre configuration? Le processus le plus récent est pointé vers -sf 12488(et 12488n'est pas en cours d'exécution), mais il ressemble à 12483celui vers lequel il devrait pointer pour prendre l'auditeur avec succès.

— Shane Madden

Un strace -p 13483pourrait aider à montrer ce que fait ce processus (ou bloqué, etc.).

— wurtel

ShaneMadden , tous les processus possèdent des écouteurs, mais seul le dernier processus écoute vraiment TCP (basé sur netstat). Le processus 12488 n'existe plus, il s'est en quelque sorte terminé. wurtel , strace montre la répétition de:gettimeofday({1417009573, 706535}, NULL) = 0 gettimeofday({1417009573, 706629}, NULL) = 0 epoll_wait(0, {}, 200, 1000)

— Bastien974

@ Bastien974 Avez-vous pu trouver la solution du problème. Je vois le même problème.

— pradeepchhetri

Cela m'est arrivé aussi il y a quelques jours à peine ... Aucune réponse raisonnable, probablement, le processus n'a jamais été terminé à cause des connexions qui l'utilisent toujours tout le temps. J'ai 2 HaProxy et, cette situation ne s'est jamais produite dans le secondaire car il n'a pas de connexions pendant le fonctionnement normal.

J'ai émis une commande SIGTERM , ou vous pouvez simplement TUER l'ancien PID et tout va bien.

Vous pouvez simplement obtenir l'ancien PID à partir de la page d'état HaProxy . Rafraîchissant plusieurs fois, je voyais au hasard l'ancien et le nouveau processus.

Après avoir tué l'ancien, le nouveau processus était le seul à répondre aux demandes.

— Iñigo InThe Cloud
source