В последние пару дней почтовый сервер 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
строки, которые кажутся связанными с моим перезапуском демона.
Я попытался настроить 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 -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