snmpd перестает отвечать (Centos 6)

В последние пару дней почтовый сервер 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)
1
задан 23 March 2016 в 10:38
1 ответ

И оказалось, что мой демон 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 
1
ответ дан 3 December 2019 в 23:49

Теги

Похожие вопросы