Event: ノードがパニックから回復しました。パニックに関する情報は、次のファイルに記録されます: var tmp panic

Summary: この記事では、ユーザーおよびテクニカル サポートが「ノードがパニックから回復しました」イベントまたはメッセージを管理する方法について説明します。行動する前に、記事のすべての部分を確認してください。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

EVENT
パニックから回復したノードが1つ以上あることを示すイベント通知を受信しました。パニックに関する情報は、次の場所にあるファイルに記録されます。 /var/tmp/ 影響を受けるノード上
例： 
4.3394   03/12 18:02 W    4    53125     Node 4 has recovered from a panic. Info about panic is recorded in file: /var/tmp/panic.1615590175

Cause

ノード パニックの正確な原因はさまざまですが、一般的な原因は次のとおりです。
  • ハードウェア障害
  • ソフトウェア コードの障害
  • 間違った構成
パニックの正確な原因については、PowerScaleサポートを使用してクラスター ログの分析を実行する必要があります。

Resolution

問題のトラブルシューティングを開始するには、まずノードがパニック イベントからリカバリーし、ダウンまたはオフラインになっていないことを確認します。*

トラブルシューティングを行うには、ノードへのSSH接続を開き、「root」アカウントを使用してログインします。
次のコマンドを実行して、ノードがクラスターに再参加したことを確認します。 
# isi status
「 isi status コマンドを実行すると、次のような出力が返されます。ノードが正常にクラスターに再参加した場合、[Health]列に「D」(ダウン)は表示されません。 
                   Health  Throughput (bps)  HDD Storage      SSD Storage
ID |IP Address     |DASR |  In   Out  Total| Used / Size     |Used / Size
---+---------------+-----+-----+-----+-----+-----------------+-----------------
  1|10.16.141.226  | OK  | 553M| 3.2M| 557M|61.9T/ 106T( 59%)|        L3:  1.5T
  2|10.16.141.227  | OK  | 481M| 96.0| 481M|62.2T/ 106T( 59%)|        L3:  1.5T
  3|10.16.141.228  | OK  | 372k| 332k| 704k|62.3T/ 106T( 59%)|        L3:  1.5T
  4|10.16.141.229  | OK  |10.8M| 941k|11.7M|62.6T/ 106T( 59%)|        L3:  1.5T
  5|10.16.141.230  | OK  | 9.4M| 393k| 9.8M|62.6T/ 106T( 59%)|        L3:  1.5T
  6|10.16.141.231  | OK  | 7.3M|256.0| 7.3M|63.4T/ 106T( 60%)|        L3:  1.5T
---+---------------+-----+-----+-----+-----+-----------------+-----------------
Cluster Totals:          | 1.1G| 4.9M| 1.1G| 375T/ 634T( 59%)|        L3:  8.7T

     Health Fields: D = Down, A = Attention, S = Smartfailed, R = Read-Only
次のコマンドを実行してログを収集し、パニックの分析のためにログ セットをIsilonテクニカル サポートに提供します。 
# isi_gather_info -f /var/tmp/
 
注： /var/tmp/ パニック データはデフォルトのログ収集では収集されません。必ず isi_gather_info -f /var/tmp/ 適切なパニック情報を収集します。

ログを受信すると、テクニカル サポートはパニック スタックの詳細を確認して分析します。パニック スタックが既知の問題またはナレッジベース記事に対応しているかどうかを判断します。パニック スタックの詳細が既知の問題または既存のKB記事と一致しない場合、問題はエスカレーションされてさらに評価されます。テクニカル サポートは、ハードウェアの交換、コード修正、ファームウェア アップデート、その他の軽減策など、必要なアクションを決定します

*ノードがまだダウンしている場合は、ノードをオンラインに戻すために追加のトラブルシューティングを実行する必要があります。サポートが必要な場合は、Isilonテクニカル サポートにお問い合わせください。

詳細については、記事55936を参照してください。Isilon OneFS：イベント通知：Node Offline - Event ID: 200010001、300010003、399990001、900160001、910100006、400150007

Additional Information

注：
  • この新しいイベント通知は、OneFS v8.1.2.0、v8.2.2.0、v9.1.0.5用の2021年3月のロールアップ パッチの一部として有効になっています。2021年3月のロールアップ パッチ(RUP)より前のOneFSバージョンを実行しているクラスターでは、このイベント通知は送信されません。
  • OneFS 9.2、9.3、9.4以降にはすべてこの機能が搭載されています。
  • ノード パニックが原因でOneFSが再起動を検出すると、アップデートによってイベントがトリガーされます。
  • このイベントには、問題の理解とトラブルシューティングに役立つコア ダンプ ヘッダーなどの基本情報が含まれる場合があります。
  • 結果として得られるオートコールSRには、トリアージと分析のために、読み取り可能な形式で追加情報を含めることができます。

注：この機能は、2021年3月のRUPのインストール前にクラスターに存在する可能性のある以前のパニック イベント、コア、またはミニダンプが原因で誤ったアラームを引き起こす可能性があります。OneFSは、削除されるまで古いパニック ファイルのアラートを継続する場合があります。誤ったアラームを回避するには、次の手順を実行します。
  1. ログを強制的にローテーションして、メッセージ ログをクリーンアップします。この機能では、messages.0.gz、messages.1.gzなどのgzアーカイブ内のローテーションされたログのパニック情報はチェックされません。次のコマンドを実行して、パニックが検出されるたびに/var/log/messagesをローテーションします。
isi_for_array 'grep "panic @ time" /var/log/messages && newsyslog -F /var/log/messages'.
  1. エラー コードまたはメッセージの診断を支援するため、 /var/crash コアまたはミニダンプ ファイルの各ノードのディレクトリー。承認を得た後、それらを削除またはバックアップします。
  2. 次のコマンドを実行してクリーンアップします vmcore ファイルは次の場所にあります /var/crash すべてのノード上。
isi_for_array 'find /var/crash/ -name "vmcore*" -delete'

Affected Products

PowerScale OneFS

Products

Isilon
Article Properties
Article Number: 000184828
Article Type: Solution
Last Modified: 18 Sept 2025
Version:  15
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.