Мой check_mk сервер подключается к нескольким узлам RHEL, которые установили check_mk_agent (версия 1.2.4p3). Группа этих узлов принадлежит кластеру кардиостимуляторов.
Агент check_mk настроен по умолчанию - настроена служба xinet привязанная к порту 6556 / TCP:
service check_mk
{
type = UNLISTED
port = 6556
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/check_mk_agent
# If you use fully redundant monitoring and poll the client
# from more then one monitoring servers in parallel you might
# want to use the agent cache wrapper:
#server = /usr/bin/check_mk_caching_agent
# configure the IP address(es) of your Nagios server here:
#only_from = 127.0.0.1 10.0.20.1 10.0.20.2
# Don't be too verbose. Don't log every check. This might be
# commented out for debugging. If this option is commented out
# the default options will be used for this service.
log_on_success =
disable = no
}
Один из этих узлов кластера имеет проблемы, когда сокет открыт для порта 6556 / TCP, потому что / usr / bin / check_mk_agent сценарий зависает на этапе обнаружения кластера:
crm_mon -1 -r | grep ···
Это вызывает проблемы с отчетом сервера check_mk на этом узле.
Когда я комментирую команды обнаружения кластера в скрипте check_mk_agent, он отлично работает
# Heartbeat monitoring
# Different handling for heartbeat clusters with and without CRM
# for the resource state
###if [ -S /var/run/heartbeat/crm/cib_ro -o -S /var/run/crm/cib_ro ] || pgrep crmd > /dev/null 2>&1; then
### echo '<<<heartbeat_crm>>>'
### crm_mon -1 -r | grep -v ^$ | sed 's/^ //; /^\sResource Group:/,$ s/^\s//; s/^\s/_/g'
###fi
###if type cl_status > /dev/null 2>&1; then
### echo '<<<heartbeat_rscstatus>>>'
### cl_status rscstatus
###
### echo '<<<heartbeat_nodes>>>'
### for NODE in $(cl_status listnodes); do
### if [ $NODE != $(echo $HOSTNAME | tr 'A-Z' 'a-z') ]; then
### STATUS=$(cl_status nodestatus $NODE)
### echo -n "$NODE $STATUS"
### for LINK in $(cl_status listhblinks $NODE 2>/dev/null); do
### echo -n " $LINK $(cl_status hblinkstatus $NODE $LINK)"
### done
### echo
### fi
### done
###fi
Эта проблема не обнаружена в остальных узлах кластера.
Я уверен, что это не проблема сети, потому что такое же поведение происходит, когда соединение открывается изнутри неисправного узла:
telnet 127.0.0.1 6556
Самое странное то, что Я запускаю команду crm_mon -1 -r
вручную много раз в день, но никогда не зависает.
Что может сделать команда crm_mon -1 -r
держаться только один узел когда он выполняется без подключенного терминала?
Спасибо заранее
обновление 1
Я создал новый xinetd сервис похож на check_mk, но меняет имя, номер порта и сервер. Серверный скрипт содержит только эти строки
#!/bin/bash
unset LANG
export LC_ALL=C
date
/usr/sbin/crm_mon -1 -r -N
#/usr/sbin/crm_resource -L
date
и он тоже виснет. Я даже пытался использовать crm_resource -L
, вывод которого такой же, но тоже зависает:
# telnet 127.0.0.1 6557
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Fri Jul 14 08:37:36 CEST 2017
обновление 2
Конфигурация SELinux Disabled
.
Какая у вас конфигурация SELinux?
Check_mk, вызванный через xinetd, будет иметь другой контекст, чем если бы он был вызван из корневой оболочки. Я видел, как это мешает удаленному исполнителю плагина Nagios, похоже, это может иметь такой же эффект на check_mk.
Посмотрите, применяет ли SELinux:
$ getenforce
Установите его в разрешающий режим и посмотрите, сохраняется ли проблема:
$ setenforce 0
Если это проблема, я бы рекомендовал настроить политику SELinux с помощью autdit2allow вместо отключения SELinux.
См. Эту ссылку для получения информации об использовании audit2allow: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html