最近まで正常に動作していたPERC5/iコントローラーを搭載したRedHat5.1サーバー64ビットDell2950を持っています。
その上に、エラーを返し始めたNRPEコマンドcheck_openmangeがあります。
/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.
明らかに、これらのコンポーネントは、システムが稼働しているときに存在します。 Dell Open ManageのWebインターフェイスにアクセスできますが、すべてが緑色であると報告されます。
Openmangeがomreportツールを使用していることを確認すると、上記のエラーが直接生成されます。
[root@lynx tmp]# omreport storage controller
No controllers found
OMSAと64ビットRHEL5およびCentOS5の問題に関連するスレッドがオンラインで多数見つかりました。これらのスレッドでは、64ビットシステムで32ビットソフトウェアを実行することを提案しています。
ただし、私はすでに32ビットソフトウェアを実行しています。
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
さらに、これらの投稿のほとんどはPERC 4に関連しているようで、私のものはPERC 5です。このチェックとレポートは最近まで安定しており、数か月間本番環境に負荷がかかっていたため、これらの手順を実行するのをためらっています。しかし、なぜこの振る舞いが変わったのかについての良い兆候は見つかりませんでした。
誰かがPERC5でこの問題を経験しましたか?
誰かが診断の手順や解決策についてさらに考えていますか?
OMSA(service dataeng restart
)を再起動し、IPMIがロードされていることを確認する基本的なトラブルシューティング手順を完了したと仮定します。
service dataeng stop
service dsm_sa_ipmi start
service dataeng start
この問題の一般的な非自明な原因の1つは、システムセマフォの枯渇です。システムログを確認してください。このようなものが表示された場合:
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
その後、セマフォが不足しています。
ipcs -s
を実行して、システムに現在割り当てられているすべてのセマフォを一覧表示してから、ipcrm -s <id>
を使用してセマフォを削除できます(不要になったと合理的に確信できる場合)。また、それらを作成したプログラムを追跡して(ipcs -s -i <id>
からの情報を使用して)、セマフォがリークしていないことを確認することもできます。ただし、私の経験では、ほとんどのリークは、クリーンアップコードを実行する前に(セグメンテーション違反などによって)中断されたプログラムから発生します。
システムで現在割り当てられているすべてのセマフォが本当に必要な場合は、使用可能なセマフォの数を増やすことができます。 sysctl -a | grep kernel.sem
を実行して、現在の設定を確認します。最終的な数は、システムで使用可能なセマフォの数です(通常は128)。その行を/etc/sysctl.conf
にコピーし、最終的な数値をより大きな値に変更して保存し、sysctl -p
を実行して新しい設定をロードします。
これが失敗した場合:
omreportシャーシメモリ メモリ情報 エラー:メモリオブジェクトが見つかりません
Srvadmin-services.shを停止します。
srvadmin-services.sh停止
次のコマンドを使用して、last-opパラメータが「未設定」のセマフォをクリアできます。
for i inʻipcs -st | grep "Not set" |カット-d '' -f1`; do(ipcrm -s $ i); echo -e "$ iclear。";完了
Srvadmin-services.shを起動します。
srvadmin-services.sh start
NagiosのジョブがOpenmanageをチェックするようにスケジュールされているホストでこれに遭遇しました。それは、Nagiosが所有する多数の古いセマフォとして現れます。
私は毎晩cron
の仕事をして、10分間隔で2つのリストを取得するだけで、古いものを見つけました。両方のリストに存在するものはすべて古くなっていると見なされます。 (もちろん、状況に合わせて調整してください。)
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
Asciiphilの指示に従うことは私のために働いた。私の場合、nrpe
には、オープン管理に関連する多くのセマフォが開かれていました。それらを一掃し、すべてを再起動しました。
これは失敗しました:
omreport chassis memory
Memory Information
Error : Memory object not found
十分なセマフォがあることを確認してください。
sysctl -a | grep kernel.sem
ipcs -s |wc -l
nrpe
を使用するomreport
を停止します。
/etc/init.d/nrpe stop
nrpe
セマフォを削除します:
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
それがうまく始まったことを確認してください
tail -n 50 /var/log/messages
テスト:
omreport chassis memory
再起動nrpe
:
/etc/init.d/nrpe restart