Alguém sabe como consertar problemas com o omsa no red hat 5.1 que informa “No controllers found”?

Question

Eu tenho um servidor Red Hat 5.1 de 64 bits Dell 2950 com um controlador PERC 5 / i que até recentemente funcionava bem.

Nela eu tenho um comando check_openmange do NRPE que começou a retornar erros:

/usr/local/nagios/libexec/check_openmanage
Storage Error! No controllers found
Problem running 'omreport chassis memory': Error: Memory object not found
Problem running 'omreport chassis fans': Error! No fan probes found on this system.
Problem running 'omreport chassis temps': Error! No temperature probes found on this system.
Problem running 'omreport chassis volts': Error! No voltage probes found on this system.

Obviamente, esses componentes existem enquanto o sistema está ativo e em execução. Eu posso acessar a interface da web para o Dell Open Manage e ele informa que tudo está verde.

Verifique que openmange usa a ferramenta omreport e isso gera o erro acima diretamente:

[root@lynx tmp]# omreport storage controller
No controllers found

Encontrei vários tópicos on-line relacionados a problemas com o OMSA e o RHEL 5 e o CentOS 5 de 64 bits, nos quais eles sugerem a execução do software de 32 bits em sistemas de 64 bits:

• link

No entanto, eu já estou executando o software de 32 bits:

Installed Packages
Name   : srvadmin-storage
Arch   : i386
Version: 6.5.0
Release: 1.201.2.el5
Size   : 8.4 M
Repo   : installed
Summary: Storage Management accessors package, 3.5.0

Além disso, a maioria desses posts parece relacionada a um PERC 4 e o meu é um PERC 5. Esse teste e relatório permaneceram estáveis até recentemente e ele tem carga de produção há vários meses, o que me deixa hesitante em seguir esses passos. No entanto, não encontrei nenhuma boa indicação de por que esse comportamento mudou.

Alguém já experimentou esse problema com o PERC 5?

Alguém tem mais ideias sobre etapas ou soluções de diagnóstico?

    

Answer 1

Suponho que você tenha feito as etapas básicas de solução de problemas ao reiniciar o OMSA ( service dataeng restart ) e garantir que o IPMI esteja carregado:

service dataeng stop
service dsm_sa_ipmi start
service dataeng start

Uma causa comum não óbvia deste problema é o esgotamento do semáforo do sistema. Verifique seus logs do sistema; se você vir algo assim:

Server Administrator (Shared Library): Data Engine EventID: 0  A semaphore set has to be created but the system limit for the maximum number of semaphore sets has been exceeded

você está sem semáforos.

Você pode executar ipcs -s para listar todos os semáforos alocados no seu sistema e usar ipcrm -s <id> para remover um semáforo (se tiver certeza de que não é mais necessário). Você também pode querer rastrear o programa que os criou (usando informações de ipcs -s -i <id> ) para ter certeza de que não está vazando semáforos. Na minha experiência, porém, a maioria dos vazamentos vem de programas que foram interrompidos (por segfaults ou similares) antes que eles pudessem executar seu código de limpeza.

Se o seu sistema realmente precisa de todos os semáforos atualmente alocados, você pode aumentar o número de semáforos disponíveis. Execute sysctl -a | grep kernel.sem para ver quais são as configurações atuais. O número final é o número de semáforos disponíveis no sistema (normalmente 128). Copie essa linha para /etc/sysctl.conf , altere o número final para um valor maior, salve-o e execute sysctl -p para carregar as novas configurações.

    

Answer 2

Eu encontrei isso em um host onde um trabalho do Nagios estava agendado para verificar o Openmanage. Ele se manifestaria como um grande número de semáforos obsoletos de propriedade do Nagios.

Eu coloco um trabalho noturno de cron para encontrar os trabalhos obsoletos simplesmente pegando duas listagens com 10 minutos de intervalo; qualquer coisa presente em ambas as listas é considerada obsoleta. (Ajuste para as suas circunstâncias, obviamente.)

nagioi () {
    ipcs -a | awk '$3 == "nagios" { print $2 }'
}

# Run two listings, 10 minutes apart
# The ones which are in both listings are definitely stuck
(nagioi; sleep 600; nagioi) |
sort | uniq -d |
xargs -n 1 -r -t ipcrm -s

    

Answer 3

Para isso, falhou:

omreport chassis memory
Memory Information
Error : Memory object not found

Pare o srvadmin-services.sh:

srvadmin-services.sh stop

O seguinte comando pode ser usado para limpar os semáforos com o último parâmetro op "Not set":

for i in 'ipcs -st |grep "Not set"| cut -d ' ' -f1'; do (ipcrm -s $i); echo -e "$i clear."; done

Inicie o srvadmin-services.sh:

srvadmin-services.sh start

    

Answer 4

Seguir as intruções do asciiphil funcionou para mim. No meu caso, nrpe tinha muitos semáforos abertos relacionados ao gerenciamento aberto. Limpou-os e reiniciou tudo.

Isso falhou:

omreport chassis memory
Memory Information

Error : Memory object not found

Certifique-se de que existem semáforos suficientes:

sysctl -a | grep kernel.sem
ipcs -s |wc -l 

Pare nrpe , que usa omreport :

/etc/init.d/nrpe stop

Remover nrpe semaphores:

ipcs -s | awk '/nrpe/ {print "ipcrm -s ",$2}  ' | sh 
/etc/init.d/dataeng stop
/etc/init.d/dsm_sa_ipmi stop
/etc/init.d/dsm_sa_ipmi start
/etc/init.d/dataeng start

Certifique-se de que começou bem

tail -n 50 /var/log/messages

Teste:

omreport chassis memory

Reinicie o nrpe :

/etc/init.d/nrpe restart

    

Answer 5

Experimente /etc/init.d/dataeng start e /etc/init.d/dsm_om_shrsvc start