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の予約はブート・プロセスの早いため、一部のシステムでは特定の固定オフセットでメモリーを予約する必要があります。固定オフセットを指定すると、予約されたメモリーはその場所で開始します。たとえば、16 MBから開始する128 MBのメモリーを予約するには、次のようにします。
```
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
```
システムを更新します。
```
sudo dnf update -y
```
kernel-uek-debuginfoパッケージをインストールします。
```
sudo dnf install -y kernel-uek-debuginfo-$(uname -r)
```
重要

パッケージ・マネージャを使用してカーネルが更新されるたびに、インストール・コマンドを実行します。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ドキュメント