o cliente escravo apcupsd continua perdendo e restaurando as comunicações com o mestre da UPS

Question

Em um VMWare ESXI 5.0.0 (vSphere Hypervisor - a versão gratuita), tenho três imagens de servidor. Todos executando o CentOS 6 - Linux. Todos estão configurados para rodar o daemon do apcupsd ( link ) para controlar ups de APC.

Um dos servidores (mestre) está conectado, usando um cabo USB para um no-break APC CS 350. O apcupsd está configurado para ter o netserver disponível na porta 3551.

Os outros dois servidores (também virtualizados) foram configurados para recuperar o status do UPS do mestre.

Funciona, mas vejo muitas advertências vindo dos dois escravos. Em uma janela de terminal, vejo entradas dizendo

Broadcast message from root@slavehostname (Thu Nov 1 19:55:10 2012):

Warning communications lost with UPS masterhostname

Broadcast message from root@slavehostname (Thu Nov 1 19:55:47 2012):

Communications restored with UPS masterhostname

No mesmo dia, vejo cerca de 200 conjuntos de mensagens perdidas / restauradas. Eles são muito mais frequentes durante o dia do que durante a noite.

Eu não recebo nenhum aviso no mestre.

Esses servidores têm muita memória e CPU disponíveis para eles. Praticamente sem troca ocorrendo. Eu não acho que eles estão famintos. E geralmente eles não fazem muito trabalho.

Esta é a configuração mestre (deixando de fora as configurações da EPROM):

UPSCABLE usb
UPSTYPE usb
DEVICE
POLLTIME 10
LOCKFILE /var/lock
SCRIPTDIR /etc/apcupsd
PWRFAILDIR /etc/apcupsd
NOLOGINDIR /etc
ONBATTERYDELAY 6
BATTERYLEVEL 5
MINUTES 3
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
NETSERVER on
NISIP 0.0.0.0
NISPORT 3551
EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 10
UPSCLASS standalone
UPSMODE disable
STATTIME 0
STATFILE /var/log/apcupsd.status
LOGSTATS off
DATATIME 0

E esta é a configuração do escravo:

UPSCABLE ether
UPSTYPE net       
DEVICE 192.168.0.59:3551
POLLTIME 10
LOCKFILE /var/lock
SCRIPTDIR /etc/apcupsd
PWRFAILDIR /etc/apcupsd
NOLOGINDIR /etc
ONBATTERYDELAY 12
BATTERYLEVEL 10
MINUTES 7
TIMEOUT 0
ANNOY 300
ANNOYDELAY 60
NOLOGON disable
KILLDELAY 0
NETSERVER on
NISIP 0.0.0.0
NISPORT 3551
EVENTSFILE /var/log/apcupsd.events
EVENTSFILEMAX 10
UPSCLASS standalone
UPSMODE disable
STATTIME 20
STATFILE /var/log/apcupsd.status
LOGSTATS off
DATATIME 0

Eu gostaria de pedir ajuda sobre como seguir em frente. Como faço para depurar isso? Qualquer sugestão sobre como eu poderia ter configurado meus servidores de uma maneira que poderia causar isso.

    

Answer 1

Isso não corrige o problema subjacente, mas ajuda a limpar um pouco o console:

O script que gera essas mensagens é chamado apccontrol , e no meu Ubuntu 12.04.02 LTS boxen vive em /etc/apcupsd . Usa wall para todas as mensagens.

Mas também chama outros scripts, se existirem nesse diretório, para fazer manipulações secundárias, como o envio de e-mails para o root toda vez que houver uma falha de comunicação. Você pode desativar isso movendo o script ou alterando-o.

Além disso: se o outro script sair com o código de status 99, o apccontrol não chamará a ação padrão e você não receberá spam na sua parede.

Acabei de usá-lo para empurrar todos os alertas de perda de comunicação para o syslog em vez de wall, e agora ele não sobrecarrega todos os terminais que estou tentando usar. E eu posso colocar a polltime de volta ao padrão de 60, então minha caixa de escravos ainda vai notar se o no-break entrar em ação.

    

Answer 2

Eu sei que este é um post antigo, mas minha experiência pode ser útil ...

Eu originalmente forneci meu servidor por meio de um APC BackUPS 650CS. Isso sempre funcionou bem.

Eu fiz o upgrade para um APC BX1100CI-MS. Esta configuração deu muitos problemas - mensagens 'Comunicações perdidas' na máquina escrava, o acesso frequente levou cinco segundos, ou mais, para produzir sua saída. Outra peculiaridade é que o apcupsd relatou status de 'energia perdida / energia restaurada' cerca de três vezes por segundo, durante vários segundos, quando a energia foi desligada. Pior de tudo, essa configuração exigia uma troca de bateria a cada dois ou três meses. A APC trocou a unidade completa três vezes antes de se render e me deu um BackUPS Pro BR1200 em troca.

Esta nova configuração não produziu uma única mensagem 'Comunicações perdidas', apenas gera uma única mensagem de 'perda de energia', e o apacaccess produz uma saída instantânea. Espero para ver como dura a bateria.

Minha suspeita é que os modelos APC posteriores mudaram ligeiramente o protocolo de controle e o apcupsd não resolve.

    

Answer 3

Experimentando o mesmo. Parece um bug no apcupsd. Tente aumentar o POLLTIME no escravo, isso diminuirá drasticamente a taxa de erro.

    

Answer 4

No arquivo de configuração do servidor conectado ao UPS

"UPSCLASS autônomo"

provavelmente deveria ser

"UPSCLASS netmaster"