В последние пару дней почтовый сервер Centos 6.7, за которым я наблюдаю, постоянно отключается по таймауту для запросов snmp. За период, непосредственно предшествующий изменению поведения (я знаю ...), на сервере не было внесено никаких изменений, поэтому я склонен винить "что-то" в среде.
Если я перезапущу демон, он снова будет реагировать в течение нескольких минут (до пары часов), затем снова начнется тайм-аут. Это также произойдет для запросов, выполняемых с самого компьютера, как в
# snmpstatus -v1 -c public localhost
(так что на рисунке нет проблем с сетью). У меня нет ничего примечательного в dmesg, и единственное, что я вижу в / var / log / messages - это не обычные трассировки подключения snmp - случайные:
Mar 22 17:34:53 turnip snmpd[31053]: read:Interrupted system call
строки, которые кажутся связанными с моим перезапуском демона.
I пытался настроить snmpd, и я вижу, что он ждет в цикле выбора / приема - когда он не отвечает, он никогда не выходит оттуда и ничего не записывает в журналы - это как если бы пакеты не доставлялись в демон. Но перезагрузка машины не имеет никакого эффекта.
Также неэффективными были попытки настроить ограничение на количество открытых файлов и изучение других возможных ограничений ресурсов - не говоря уже о том, что сама машина особо не нагружена. Так что у меня в настоящее время нет подсказок.
Я могу опубликовать snmpd.conf, если необходимо.
TIA и приветствия
Редактировать: так выглядит отслеживаемый цикл (пока не отвечает):
select(15, [14], NULL, NULL, {0, 27618}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
И оказалось, что мой демон snmpd запускает ряд команд (оболочки), указанных в расширяемом разделе snmpd.conf. Один из них (по причинам, которые еще предстоит определить) начал время от времени заклинивать. Глупый демон snmpd застрял при чтении этой команды, и время ожидания всего shebang истекло.
То, как я узнал, может представлять интерес.
1) найти pid snmpd:
#pidof snmpd
124567
2) strace it:
# strace -p124567
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
select(15, [14], NULL, NULL, {1, 0}) = 0 (Timeout)
3) 14 - дескриптор файла, на котором застрял snmpd. Теперь найдите его индексный дескриптор:
# ls -l /proc/1124567/fd
total 0
lrwx------ 1 root root 64 Mar 23 10:41 0 -> /dev/null
lrwx------ 1 root root 64 Mar 23 10:41 1 -> /dev/null
[...]
lr-x------ 1 root root 64 Mar 23 10:41 14 -> pipe:[6200340]
4) Теперь найдите процесс (а) на другом конце канала, идентифицированный индексным индексом 6200340. Этот скрипт - вызываемый с индексным дескриптором в качестве аргумента - полезен для этой цели:
#!/bin/bash
for i in /proc/*/fd; do
found=$(ls -l $i| fgrep $1)
if [[ x$found != x ]]; then
pid=$(basename $(dirname $i))
name=$(ps -p $pid -o comm=)
echo "$name ($pid)"
fi
done