Назад | Перейти на главную страницу

check_mk_agent зависает при запуске проверки кластера ТОЛЬКО при запуске по сети

Мой 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