Kdumpユーティリティを使用したクラッシュ・ダンプの収集

Oracle Linuxシステムでカーネル・パニックが発生し、予期せずクラッシュしたり、応答が停止したりすると、システム状態およびクラッシュに至るカーネル・コールに関する情報がトラブルシューティングに役立つ場合があります。Kdump機能は、カーネル・クラッシュ情報用のダンプ・メカニズムを提供します。Oracle Linuxのプラットフォーム・イメージでは、イメージのリリース日に応じて、OSは完全に構成されるか、クラッシュ・ダンプを生成するように部分的に構成されます。

ノート

デプロイ済のカスタムおよびマーケットプレイスのLinuxイメージの場合は、コマンドラインを使用してKdumpをインストールおよび構成します。

Kdumpには、システム・メモリーの予約部分にある2番目のカーネルが含まれており、停止したカーネルに関する情報を取得できます。Kdumpは、kexecシステム・コールを使用して2番目のカーネル(キャプチャ・カーネル)をブートし、システムをリボートしなくても、停止したカーンのメモリーの内容をクラッシュ・ダンプとして取得します。クラッシュ・ダンプの内容の詳細は、「Linuxカーネル・コア・ダンプの内部」を参照してください。

Oracle Linuxインスタンスの場合、Kdumpによって収集されたクラッシュ・ダンプ情報は、デフォルトで/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>ディレクトリにコピーされます。クラッシュ・ダンプごとに、新しい<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>ディレクトリが作成されます。たとえば:

[opc@<instance_name> crash] ls -a

127.0.0.1-2025-02-07-15:18:07
127.0.0.1-2025-02-07-16:28:19

ダンプ・ディレクトリには、クラッシュ・ダンプ・ファイルvmcore、テキスト・ファイルおよびログ・ファイルが含まれます。次に例を示します。

[opc@<instance_name> <127.0.0.1-2025-02-07-16:28:19>] ls -a

vmcore
vmcore-dmesg.txt
kexec-dmesg.log

重要

Oracle Linuxインスタンスにアクセスできないか、応答しない場合は、診断中断を送信してトラブルシューティングできます。診断中断によって、インスタンスのOSはクラッシュし、再起動されます。コンソールまたはAPIを使用して診断割り込みを送信するには、クラッシュ・ダンプを生成するようにKdumpを構成する必要があります。詳細は、「診断割込みの送信」を参照してください。

クラッシュダンプ用に予約されているメモリーの設定

Oracle Linuxプラットフォーム・イメージでは、Kdumpがインストールされ、デフォルトで完全に構成されるか、部分的に構成されます。crashkernelメモリー予約とも呼ばれるクラッシュダンプを保存するために、カーネルで予約されているメモリー量を変更できます。Oracle Linux 8以前では、デフォルトのメモリー予約が自動的に調整されるように設定されています: GRUB_CMDLINE_LINUX="crashkernel=auto"。ただし、crashkernel=autoはOracle Linux 9以降ではサポートされないため、crashkernelパラメータを使用して特定の量の予約済メモリーを設定する必要があります。

クラッシュ・ダンプのメモリー予約を設定するには:

コマンドラインから、管理権限を使用してSSHを使用してインスタンスに接続します。
/etc/default/grubファイルを編集して、予約済メモリーを設定します。例:
- 次のように、メモリー予約を64MBに設定します。
```
GRUB_CMDLINE_LINUX="crashkernel=64MB"
```
- crashkernel=<range1>:<size1>,<range2>:<size2>構文で、予約済メモリーの量を変数として設定します。例:
```
GRUB_CMDLINE_LINUX="crashkernel=512M-2G:64M,2G-:128M"
```
- 予約済メモリーのオフセット値の定義。crashkernelの予約は非常に早い段階で発生するため、一部のシステムでは特定の固定オフセットでメモリーを予約する必要があります。固定オフセットを指定すると、予約されたメモリーはその場所で開始します。たとえば、128MBのメモリーを予約するには、16MBから開始します。
```
GRUB_CMDLINE_LINUX="crashkernel=128M@16M"
```
変更を保存し、grub構成をリフレッシュします。
```
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
```
インスタンスを再起動して変更を適用します。

クラッシュダンプの場所の変更

/etc/kdump.confを使用すると、クラッシュ・ダンプ・ファイルの保存場所を変更したり、SSH経由で転送したり、ネットワーク共有にエクスポートしたりできます。

コマンドラインから、管理権限を使用してSSHを使用してインスタンスに接続します。
/etc/kdump.confファイルで構成ファイルを編集し、有効にする各行の先頭にある#コメント文字を削除します。
- クラッシュ・ダンプ・ファイルのデフォルト・ディレクトリ(/var/oled/crash)を変更します。たとえば:
```
path /usr/local/<cores>
```
- セキュア・シェル接続を介してクラッシュ・ダンプ・ファイルを転送します。たとえば:
```
ssh <user@example.com>
sshkey /root/.ssh/<mykey>
```
- 互換性のあるネットワーク共有にエクスポートするクラッシュダンプファイルを設定します。次に例を示します。
```
nfs <example.com>:/<output>
```
詳細は、/usr/share/man/man5/kdump.conf.5.gzアーカイブのkdump.conf.5ファイルを参照してください。
終了したら、変更を保存し、kdumpサービスを再起動します。
```
sudo systemctl restart kdump.service 
```
インスタンスを再起動して変更を適用します。

デフォルトの障害状態の変更

デフォルトでは、Kdumpで、構成されているの出力場所への結果の送信に失敗すると、サーバーが再起動されます。このアクションにより、ダンプ用に収集されたデータがすべて削除されます。この結果を回避するには、Kdump構成を変更します。

コマンドラインから、管理権限を使用してSSHを使用してインスタンスに接続します。
/etc/kdump.confを編集してコメントを解除し、ファイルのdefault値を次のように変更します。
```
default dump_to_rootfs
```
dump_to_rootfsオプションは、結果をローカル・ディレクトリに保存しようとします。これは、ネットワーク共有にアクセスできない場合に便利です。かわりにshellを使用して、コマンドラインからデータを手動でコピーできます。
ノート

poweroff、restart、および haltオプションは、デフォルトの kdump障害状態でも有効です。ただし、これらのアクションを実行すると、収集されたデータが失われます。詳細は、/usr/share/man/man5/kdump.conf.5.gzアーカイブのkdump.conf.5ファイルを参照してください。
終了したら、変更を保存し、kdumpサービスを再起動します。
```
sudo systemctl restart kdump.service
```
インスタンスを再起動して変更を適用します。

クラッシュダンプのトリガー

クラッシュ・ダンプを収集するサービスをトリガーするカーネルをクラッシュして、Kdump構成をテストします。次に、クラッシュ・ダンプを確認します。

コマンドラインから、管理権限を使用してSSHを使用してインスタンスに接続します。
Kdumpが実行されていることを確認します。
```
systemctl is-active kdump
```
コンソールまたはコマンド行からクラッシュを開始します。
```
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
```
これにより、カーネルは強制的にクラッシュし、ダンプ・ファイルは、デフォルトで/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>ディレクトリ、または構成で選択した場所にコピーされます。
Reboot the instance.
SSHを使用してインスタンスに再接続し、/var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>のクラッシュ・ダンプ・ファイルを確認します:
- カーネル・メッセージ・バッファには、システム・クラッシュに関する最も重要な情報が含まれており、常にvmcore-dmesg.txtファイルに最初にダンプされます。これは、ターゲットの場所に領域がないなど、完全なvmcoreファイルの取得に失敗した場合に便利です。
- kexecツールが2番目のカーネルにブートし、クラッシュしたカーネルのメモリーの内容を取得すると、プロセスをトレースできるようにkexec-dmes.logファイルにも書き込まれます。たとえば、ファイルの最後に、クラッシュ・ダンプの保存プロセスを確認できます。
```
...
Feb 07 16:28:19 linux9 systemd[1]: Starting Kdump Vmcore Save Service...
Feb 07 16:28:19 linux9 kdump[504]: Kdump is using the default log level(3).
Feb 07 16:28:19 linux9 kdump[541]: saving to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/
Feb 07 16:28:19 linux9 kdump[546]: saving vmcore-dmesg.txt to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19/
Feb 07 16:28:19 linux9 kdump[552]: saving vmcore-dmesg.txt complete
Feb 07 16:28:19 linux9 kdump[554]: saving vmcore
Feb 07 16:28:21 linux9 kdump.sh[555]: 
Checking for memory holes                         : [  0.0 %] /                  
...
Copying data                                      : [100.0 %] \           eta: 0s
Feb 07 16:28:21 linux9 kdump.sh[555]: The dumpfile is saved to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//vmcore-incomplete.
Feb 07 16:28:21 linux9 kdump.sh[555]: makedumpfile Completed.
Feb 07 16:28:21 linux9 kdump[559]: saving vmcore complete
Feb 07 16:28:21 linux9 kdump[561]: saving the /run/initramfs/kexec-dmesg.log to /kdumproot/var/oled/crash/127.0.0.1-2025-02-07-16:28:19//
```
- vmcoreファイルには、クラッシュ・ダンプ情報が含まれます。クラッシュ・ダンプを分析するには、vmcoreファイル形式を読み取ることができるユーティリティが必要です。crashユーティリティの使用の詳細は、クラッシュ・ダンプの分析を参照してください。

クラッシュ・ダンプの分析

crashユーティリティを使用して、Kdumpによって収集されたクラッシュ・ダンプを分析できます。Oracle Linuxプラットフォーム・イメージでは、crashがデフォルトでインストールされます。その他のLinuxインスタンスの場合は、コマンドラインを使用してインストールします: sudo dnf install crash。

crashユーティリティを使用するためのOracle Linuxインスタンスの構成

crashを使用してクラッシュ・ダンプを分析するには、次の構成タスクを実行します。

コマンドラインから、管理権限を使用し、SSHを使用してインスタンスに接続します。
root権限および次の内容で/etc/yum.repos.d/debuginfo.repoファイルを作成して、Oracle Linux debuginfoリポジトリを有効にします。たとえば:
```
[debuginfo]
name=Oracle Linux 8 Debuginfo Packages
baseurl=https://oss.oracle.com/ol8/debuginfo/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1
```
Oracle Linux 9を使用している場合はol8をol9に置き換え、Oracle Linux 10を使用している場合はol10に置き換えます。
システムの更新:
```
sudo dnf update -y
```
kernel-uek-debuginfoパッケージをインストールします。
```
sudo dnf install -y kernel-uek-debuginfo-$(uname -r)
```
重要

パッケージ・マネージャを介してカーネルが更新されるたびに、installコマンドを実行します。debuginfoパッケージは、実行中のカーネルと一致する場合にのみ機能し、新しいカーネル・バージョンがシステムにインストールされても自動的に置換されません。

crashユーティリティを使用したクラッシュ・ダンプの分析

クラッシュ・ダンプを分析するには、crashにvmcore情報を指定し、crashシェル・オプションを使用してクラッシュ・ダンプ情報を取得します。crashユーティリティーの使用方法の詳細については、コマンドプロンプトで man crashと入力するか、crash documentationを参照してください。

コマンドラインから、管理権限を使用し、SSHを使用してインスタンスに接続します。

crashユーティリティへのパラメータとして、カーネルのdebuginfoモジュールの場所、およびコア・ダンプの位置を指定します。たとえば:

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/oled/crash/<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>/vmcore

$(uname -r)は、コマンド内で実行中のカーネル・バージョンを識別し、<ip-address>-<YYYY-MM-DD>-<HH:MM:SS>は、クラッシュ・ダンプ・ファイル用に作成されるディレクトリを表し、vmcoreファイルにはクラッシュ・ダンプが含まれます。

crashシェルが起動し、次のようなシステム・クラッシュ情報が表示されます。

KERNEL: /usr/lib/debug/lib/modules/5.15.0-302.167.6.el9uek.x86_64/vmlinux
    DUMPFILE: /var/oled/crash/127.0.0.1-2025-02-07-16:28:19/vmcore  [PARTIAL DUMP]
        CPUS: 2
        DATE: Fri Feb  7 16:28:15 GMT 2025
      UPTIME: 01:09:58
LOAD AVERAGE: 0.00, 0.02, 0.00
       TASKS: 204
    NODENAME: oci-linux9
     RELEASE: 5.15.0-302.167.6.el9uek.x86_64
     VERSION: #2 SMP Mon Nov 4 23:41:59 PST 2024
     MACHINE: x86_64  (2445 Mhz)
      MEMORY: 16 GB
       PANIC: "Kernel panic - not syncing: NMI: Not continuing"
         PID: 0
     COMMAND: "swapper/0"
        TASK: ffffffffb761a980  (1 of 2)  [THREAD_INFO: ffffffffb761a980]
         CPU: 0
       STATE: TASK_RUNNING (PANIC)

crash>

crashプロンプトで、クラッシュ・ダンプの詳細を取得するオプションを入力します。次に例を示します。

bt -aは、カーネルがパニックになったときにアクティブ・タスクのスタック・トレースを表示します。たとえば:

crash> bt -a

PID: 286    TASK: c0b3a000  CPU: 0   COMMAND: "in.rlogind"
    #0 [c0b3be90] crash_save_current_state at c011aed0
    #1 [c0b3bea4] panic at c011367c
    #2 [c0b3bee8] tulip_interrupt at c01bc820
    #3 [c0b3bf08] handle_IRQ_event at c010a551
    #4 [c0b3bf2c] do_8259A_IRQ at c010a319
    #5 [c0b3bf3c] do_IRQ at c010a653
    #6 [c0b3bfbc] ret_from_intr at c0109634
       EAX: 00000000  EBX: c0e68280  ECX: 00000000  EDX: 00000004  EBP: c0b3bfbc
       DS:  0018      ESI: 00000004  ES:  0018      EDI: c0e68284 
       CS:  0010      EIP: c012f803  ERR: ffffff09  EFLAGS: 00000246 
    #7 [c0b3bfbc] sys_select at c012f803
    #8 [c0b3bfc0] system_call at c0109598
       EAX: 0000008e  EBX: 00000004  ECX: bfffc9a0  EDX: 00000000 
       DS:  002b      ESI: bfffc8a0  ES:  002b      EDI: 00000000 
       SS:  002b      ESP: bfffc82c  EBP: bfffd224 
       CS:  0023      EIP: 400d032e  ERR: 0000008e  EFLAGS: 00000246

ps -Aは、各CPUのアクティブ・タスクのみを表示します。たとえば:

crash> ps -A

PID    PPID  CPU       TASK        ST  %MEM    VSZ    RSS  COMM
>    10      2   1  ffff880212969710  IN   0.0      0      0   [migration/1]
>     0      0   3  ffff884026d43520  RU   0.0      0      0   [swapper]
>  6582      1   2  ffff880f49c52040  RU   0.0 42202472  33368  oracle
>  9497      1   0  ffff880549ec2ab0  RU   0.0 42314692 138664  oracle

vmは、現在のコンテキストの基本的な仮想メモリー情報を表示します。たとえば:

crash> vm

PID: 30986  TASK: c0440000  CPU: 0   COMMAND: "bash"
       MM       PGD       RSS    TOTAL_VM
    c303fe20  c4789000    88k      1728k
      VMA      START      END     FLAGS  FILE
    c0d1f540   8048000   80ad000  1875   /bin/bash
    c0d1f400   80ad000   80b3000  1873   /bin/bash
    c0d1f880   80b3000   80ec000    77
    c0d1f0c0  40000000  40012000   875   /lib/ld-2.1.1.so
    c0d1f700  40012000  40013000   873   /lib/ld-2.1.1.so
    c0d1fe00  40013000  40014000    77
    c0d1f580  40014000  40016000    73
...

filesは、現在のコンテキストで開いているファイルに関する情報を示します。

crash> files

PID: 720    TASK: c67f2000  CPU: 1   COMMAND: "innd"
    ROOT: /    CWD: /var/spool/news/articles
     FD    FILE     DENTRY    INODE    TYPE  PATH
      0  c6b9c740  c7cc45a0  c7c939e0  CHR   /dev/null
      1  c6b9c800  c537bb20  c54d0000  REG   /var/log/news/news
      2  c6df9600  c537b420  c5c36360  REG   /var/log/news/errlog
      3  c74182c0  c6ede260  c6da3d40  PIPE
      4  c6df9720  c696c620  c69398c0  SOCK
      5  c6b9cc20  c68e7000  c6938d80  SOCK
      6  c6b9c920  c7cc45a0  c7c939e0  CHR   /dev/null
      7  c6b9c680  c58fa5c0  c58a1200  REG   /var/lib/news/history
      8  c6df9f00  c6ede760  c6da3200  PIPE

kmem -iは、カーネル・メモリーの使用状況情報を表示します。たとえば:

crash> kmem -i

                     PAGES        TOTAL      PERCENTAGE
        TOTAL MEM  1974231       7.5 GB         ----
             FREE   208962     816.3 MB   10% of TOTAL MEM
             USED  1765269       6.7 GB   89% of TOTAL MEM
           SHARED   365066       1.4 GB   18% of TOTAL MEM
          BUFFERS   111376     435.1 MB    5% of TOTAL MEM
           CACHED  1276196       4.9 GB   64% of TOTAL MEM
             SLAB   120410     470.4 MB    6% of TOTAL MEM
    
       TOTAL HUGE   524288         2 GB         ----
        HUGE FREE   524288         2 GB  100% of TOTAL HUGE
    
       TOTAL SWAP  2498559       9.5 GB         ----
        SWAP USED    81978     320.2 MB    3% of TOTAL SWAP
        SWAP FREE  2416581       9.2 GB   96% of TOTAL SWAP
    
     COMMIT LIMIT  3485674      13.3 GB         ----
        COMMITTED   850651       3.2 GB   24% of TOTAL LIMIT

コア・ダンプの分析が完了したら、exitまたはqを入力してシェルを終了します。

Oracle Cloud Infrastructureドキュメント