Recarga de HAProxy: los procesos antiguos nunca terminaron

15

Tengo la configuración de HAProxy en modo TCP, con un tiempo de espera de cliente / servidor / conexión de 120 s.

Cuando vuelvo a cargar la configuración demasiado rápido, a veces termino con múltiples procesos. Por diseño, esto se espera, por lo que todas las conexiones establecidas se agotan.

Mi problema es que nunca terminaron, a pesar de que todas las conexiones están cerradas.

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

Esperé más que el tiempo de espera de 120. No entiendo lo que los retiene.

El siguiente lsof para uno de esos procesos antiguos muestra que todavía hay algunos FD para 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)
Bastien974
fuente
Hmm, ¿entonces el viejo proceso aún es dueño del oyente que parece? ¿Qué está poblando -sfen su configuración? Se apunta al proceso más nuevo -sf 12488(y 12488no se está ejecutando), pero parece que 12483es al que necesitaría señalar para llevar al oyente con éxito.
Shane Madden
A strace -p 13483podría ayudar a mostrar lo que está haciendo ese proceso (o bloqueado, etc.).
wurtel
ShaneMadden , todos los procesos poseen oyentes, pero solo el último proceso realmente escucha TCP (basado en netstat). El proceso 12488 ya no existe, de alguna manera se terminó. wurtel , strace muestra la repetición de:gettimeofday({1417009573, 706535}, NULL) = 0 gettimeofday({1417009573, 706629}, NULL) = 0 epoll_wait(0, {}, 200, 1000)
Bastien974
@ Bastien974 ¿Pudiste encontrar la solución del problema? Estoy viendo el mismo problema.
pradeepchhetri

Respuestas:

1

Esto también me sucedió hace unos días ... No hay una respuesta razonable, probablemente, el proceso nunca terminó porque las conexiones todavía lo usan todo el tiempo. Tengo 2 HaProxy y esta situación nunca sucedió en la secundaria, ya que no tiene conexiones durante el funcionamiento normal.

Emití un comando SIGTERM , o simplemente puedes MATAR el PID anterior y estás bien.

Puede obtener el PID anterior en la página de estado de HaProxy . Refrescante varias veces estaba viendo el proceso antiguo y nuevo al azar.

Después de matar al antiguo, el nuevo proceso fue el único que respondió a las solicitudes.

:)

Iñigo en la nube
fuente