Meu servidor check_mk se conecta a vários nós do RHEL que instalaram o check_mk_agent (versão 1.2.4p3). Um grupo desses nós pertence a um cluster de marcapasso.
O agente check_mk é configurado por padrão - um serviço xinet é configurado vinculado à porta 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
}
Um desses nós do cluster tem problemas quando um soquete está aberto para a porta 6556 / TCP porque o script / usr / bin / check_mk_agent trava no estágio de detecção do cluster :
crm_mon -1 -r | grep ···
Isso faz com que o servidor check_mk apresente problemas nesse nó.
Quando eu comento os comandos de detecção de cluster no script check_mk_agent, ele funciona bem
# 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
Esse problema não é encontrado nos demais nós do cluster.
Tenho certeza de que não é um problema de rede, pois o mesmo comportamento ocorre quando a conexão é aberta de dentro desse nó defeituoso:
telnet 127.0.0.1 6556
O mais estranho é que eu executo o comando crm_mon -1 -r manualmente muitas vezes ao dia, mas ele nunca trava .
O que pode fazer com que o comando crm_mon -1 -r seja interrompido em apenas um nó quando é executado sem terminal conectado?
Thanx antecipadamente
atualização 1
Eu criei um novo serviço xinetd semelhante ao check_mk one, mas alterando o nome, o número da porta e o servidor. O script do servidor contém apenas estas linhas
#!/bin/bash
unset LANG
export LC_ALL=C
date
/usr/sbin/crm_mon -1 -r -N
#/usr/sbin/crm_resource -L
date
e também trava. Eu até tentei usar crm_resource -L , cuja saída é a mesma, mas ela trava também:
# 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
atualização 2
A configuração do SELinux é Disabled .