Перезавантаження HAProxy - старі процеси ніколи не припиняються


15

У мене налаштування HAProxy в режимі TCP, з клієнтом / сервером / тайм-аутом підключення 120s.

Коли я перезавантажую конфігурацію занадто швидко, я колись закінчую кілька процесів. За задумом цього очікується, тому всі встановлені з'єднання осушуються.

Моє питання полягає в тому, що вони ніколи не припинялися, хоча всі зв’язки закриті.

ps aux | гапрокси

    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

нетстат-штанги | греп гапрокси

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

Я чекав довше, ніж час очікування 120-х. Я не розумію, що їх стримує.

Наведені нижче дані про один із тих старих процесів показують, що є ще FD для 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)

Хм, значить, старий процес все ще володіє слухачем, як він виглядає? Що вказується -sfу вашій конфігурації? Новий процес вказується на -sf 1248812488не працює), але схоже, 12483це той, на який потрібно звернути увагу, щоб успішно прийняти слухача.
Шейн Медден

strace -p 13483Може допомогти показати , що цей процес робить (або заблокований на і т.д.).
wurtel

ShaneMadden , усі процеси є власниками слухачів, але лише останній процес справді слухає TCP (заснований на netstat). Процес 12488 вже не існує, його якось припинили. wurtel , strace показує повторення:gettimeofday({1417009573, 706535}, NULL) = 0 gettimeofday({1417009573, 706629}, NULL) = 0 epoll_wait(0, {}, 200, 1000)
Bastien974

@ Bastien974 Ви зуміли дізнатися рішення проблеми. Я бачу те саме питання.
pradeepchhetri

Відповіді:


1

Це трапилося і зі мною лише кілька днів тому ... Немає розумної відповіді, напевно, процес так і не закінчився через те, що зв’язки все ще використовували його. У мене є 2 HaProxy, і ця ситуація ніколи не бувала у вторинній, оскільки вона не має з'єднань під час нормальної роботи.

Я видав команду SIGTERM , або ви можете просто вбити старий PID і у вас все добре.

Ви можете просто отримати старий PID на сторінці статусу HaProxy . Освіжаючи кілька разів, я бачив старий і новий процес випадковим чином.

Після вбивства старого новий процес був єдиним, хто відповідав на прохання.

:)


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.