参考記事

EC2:SendDiagnosticInterrupt API

NITRO世代のEC2インスタンスで稼働中のOSに対し、ハードウェアNMI(マスク不可割り込み)を発生させて、OSの強制再起動が可能になりました。

NMI 割り込みを受信したときのOSの挙動は、システムの設定に依存します。
- 通常はカーネルパニックの状態に入ります。
カーネルパニックの挙動
- OSの設定に依存します。
- クラッシュダンプデータファイルの生成がトリガーされる。
- システムが再起動されたりなど。
ダンプを調べるときのルツール
- WinDbg (Windows)
- crash (Linux)

難しいことは考えずやってみた

割り込みを受信したときの OS の挙動を設定しておく

Amazon Linux 2 で、kdump と kexec をインストールおよび設定する。

sudo yum install kexec-tools

/etc/default/grub を編集する。クラッシュカーネル用に予約するメモリの量（crashkernel=150M）を割り当てる。
参考：kernel doc

/etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=150M console=tty0 console=ttyS0,115200n8 net.ifnames=0 biosdevname=0 nvme_core.io_timeout=4294967295 rd.emergency=poweroff rd.shell=0"

grub の設定を再構築する。
参考【 grub2-mkconfig／grub-mkconfig 】コマンド――GRUB 2の起動メニューを生成する

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

/etc/sysctl.confにkernel.unknown_nmi_panic=1を追加する。
1に設定すると、カーネルが未定義のNMIを検出した場合にパニックが発生します。
参考4.2.4 カーネル・パニックを制御するパラメータ

/etc/sysctl.conf

kernel.unknown_nmi_panic=1

kdump が正常に開始されていることを確認する。

systemctl status kdump.service

● kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: enabled)
   Active: active (exited) since Mon 2019-08-19 05:52:41 UTC; 1min 8s ago
  Process: 3192 ExecStart=/usr/bin/kdumpctl start (code=exited, status=0/SUCCESS)
 Main PID: 3192 (code=exited, status=0/SUCCESS)

Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: -rw-r--r--   1 root     root    ...2
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: -rw-r--r--   1 root     root    ...0
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: drwxr-xr-x   2 root     root    ...r
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: lrwxrwxrwx   1 root     root    ...k
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: lrwxrwxrwx   1 root     root    ...n
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: ================================...=
Aug 19 05:52:40 ip-10-0-0-51.ap-northeast-1.compute.internal dracut[4498]: *** Creating initramfs image fil...*
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal kdumpctl[3192]: kexec: loaded kdump kernel
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal kdumpctl[3192]: Starting kdump: [OK]
Aug 19 05:52:41 ip-10-0-0-51.ap-northeast-1.compute.internal systemd[1]: Started Crash recovery kernel arming.
Hint: Some lines were ellipsized, use -l to show in full.

API をトリガーする

aws ec2 send-diagnostic-interrupt --region us-east-1 --instance-id <value>

なお、サポートしていないインスタンスタイプの場合は↓のようなエラーが表示されたのでt2.micro→t3a.mediumにした。

An error occurred (UnsupportedOperation) when calling the SendDiagnosticInterrupt operation: This instance type does not support diagnostic interrupts.

インスタンスが再起動され、インスタンスに再接続すると、/var/crash にクラッシュダンプがあるはず。

ls -la /var/crash
total 0

kdump.conf は path /var/crash になっているんだが。。。

クラッシュダンプの内容を分析する

crash ユーティリティとデバッグシンボルをインストールしておく必要があるる。

/var/crashなかったので、とりあえずメモで。

sudo yum install crash
sudo debuginfo-install kernel
sudo crash /usr/lib/debug/lib/modules/4.14.128-112.105.amzn2.x86_64/vmlinux 

      KERNEL: /usr/lib/debug/lib/modules/4.14.123-111.109.amzn2.x86_64/vmlinux
    DUMPFILE: /proc/kcore
        CPUS: 2
        DATE: Tue Aug 20 06:49:26 2019
      UPTIME: 00:10:32
LOAD AVERAGE: 0.08, 0.02, 0.01
       TASKS: 107
    NODENAME: ip-10-0-0-51.ap-northeast-1.compute.internal
     RELEASE: 4.14.123-111.109.amzn2.x86_64
     VERSION: #1 SMP Mon Jun 10 19:37:57 UTC 2019
     MACHINE: x86_64  (2199 Mhz)
      MEMORY: 4 GB
         PID: 2829
     COMMAND: "crash"
        TASK: ffff888131238000  [THREAD_INFO: ffff888131238000]
         CPU: 0
       STATE: TASK_RUNNING (ACTIVE)

EC2 インスタンスでのカーネルパニックの生成を、リモートでトリガーする（EC2:SendDiagnosticInterrupt API）