Tutoriel Linux

最後のサービスのクラッシュをcoredumpctlで見つける

Débutant2 min de lecture

systemdサービスがダウンし、その名前はすでに分かっていますが、ログでは実際にクラッシュしたプロセスを特定するには不十分です。ユニットを再起動する前に、またはその設定を変更する前に、インシデントの時間を記録し、core dumpをcoredumpctlで検索してください。

最初のコマンドの前に、以下の点を確認してください:

  • 対象のsystemdユニットが知られていること;
  • クラッシュの大体の時間が利用可能であること;
  • ログとダンプを読むための必要な権限を持っていること;
  • ファイルは機械から出さず、そのまま共有されるべきではないこと。
コアダンプ Linux、失敗したサービスの分析前に確認
コアダンプは、制御された診断の範囲内に留まるべきです。

クラッシュの時間とプロセスから始める

ページャを開かずに利用可能なエントリを表示します:

coredumpctl --no-pager list

このコマンドは、特にTIME、PID、ユーザー、信号、ストレージの状態、および実行ファイルのパスを表示します。サービスの停止時刻に対応する行を記録してください。その後、PIDを利用して、名前が似ている二つのプロセスの混同を避けることができます。

COREFILE列は、今後の処理を示します。presentはアクセス可能なファイルを示し、journalはログに保管された内容を示します。missingは、エントリがまだ存在するがファイルが消失したことを示します。none、error、またはtruncatedの値が記載されていると、分析が制限されます。したがって、ログは関連ファイルが削除された後でもクラッシュの痕跡を保持する場合があります、特に/var/lib/systemd/coredumpで。

まだcoredumpctl debugを起動しないでください。このコマンドは、選択したダンプ上でデバッガを開きますが、自動的に原因を説明したり、サービスを復元したりすることはありません。

coredumpctl infoでターゲットダンプを読む

PIDを記録したら、そのエントリのメタデータを要求します:

coredumpctl info <PID>

リストが利用可能な実行可能ファイルのパスを提供する場合、そのパスをターゲットにします:

coredumpctl info /usr/bin/nom-executable

山かっこ内の値を出力内容に置き換えてください。このコマンドは、PID、信号、タイムスタンプ、コマンドライン、実行ファイル、使用サイズを表示します。また、Unitフィールドを通じてsystemdユニットを示し、ストレージのパスとそのステータスも明らかにすることがあります。

Unitフィールドは、ダンプをsystemd診断に関連つけます。これは落ちたサービスに対応していること、そして時間が観察された症状と一致しているか確認してください。PIDだけでは、短期間に続いた実行が複数ある場合には不十分です。完全なログアクセスがないユーザーでは、自分のプロセスのログエントリしか見ることができないこともあります。

ユニットのログとダンプを突き合わせる

ユニットの正確な名前とクラッシュの時間を取得した後、その瞬間の前後の短いウィンドウを再読します:

journalctl -u nom-unite --since "10 minutes ago" --until "now"

さらに昔のインシデントについては、相対ウィンドウを二つのタイムスタンプに置き換え、それがcoredumpctl infoで示されたものの前後を囲んでいることにします。ログはプロセスの停止、終了コードまたは信号、再起動の試行、及びクラッシュの直前に記録されたメッセージを表示する必要があります。

失敗カウンタは原因を示しません。そのユニットがfailedとしてマークされたままである場合、systemdによって追跡される状態とログに表示されるエラーの違いを思い出させるsystemctl reset-failedのガイドをご覧ください。クラッシュの前のイベントを読むためには、journalctlによるサービスのログが適切なフィルタを提供します。

ユニットのログでは不十分な場合、メッセージがドライバ、ディスク、またはカーネルに言及している場合は、dmesgでカーネルのメッセージを確認してください。この確認は、低レベルのインシデントを確認するために役立ちますが、サービスの読み取りを置き換えるものではありません。

コアダンプを制御された範囲内で保持する

コアダンプは、クラッシュの際のプロセスのメモリの一部を含む可能性があります。アプリケーションによっては、このメモリが進行中のデータ、識別子、トークン、または設定の断片を含むことがあります。このファイルは、技術的なアーティファクトに似ている名前であっても、機密データとして取り扱ってください。

coredumpctlの公式ドキュメントでは、メタデータの読み取り、dumpでの抽出、debugでのデバッガのオープンの違いを区別します。プロダクションマシンでは、分析の範囲、アクセス権、作業ストレージが確認されるまでinfoの後で停止してください。急いでのエクスポートやファイルを第三者に送信することは、失敗したサービスの名前以上の情報を曝露する可能性があります。

coredumpctlがない場合やリストが空の場合、残りの手順はディストリビューションとそのsystemd-coredumpの収集ポリシーに依存します。そのため、プロダクションを変更する前に、システムのドキュメントでこのポリシーを確認してください。