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)
A
—
wurtel
strace -p 13483podría ayudar a mostrar lo que está haciendo ese proceso (o bloqueado, etc.).
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:
—
Bastien974
gettimeofday({1417009573, 706535}, NULL) = 0 gettimeofday({1417009573, 706629}, NULL) = 0 epoll_wait(0, {}, 200, 1000)
@ Bastien974 ¿Pudiste encontrar la solución del problema? Estoy viendo el mismo problema.
—
pradeepchhetri
-sfen su configuración? Se apunta al proceso más nuevo-sf 12488(y12488no se está ejecutando), pero parece que12483es al que necesitaría señalar para llevar al oyente con éxito.