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

#参考記事#
[新着 – カーネルパニックをトリガーし、応答しない EC2 インスタンスを診断
](https://aws.amazon.com/jp/blogs/news/new-trigger-a-kernel-panic-to-diagnose-unresponsive-ec2-instances/)
[Sending a Diagnostic Interrupt (Advanced Users Only)
](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/diagnostic-interrupt.html)


#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](https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt)

```:/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の起動メニューを生成する](https://www.atmarkit.co.jp/ait/articles/1902/01/news045.html)


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

/etc/sysctl.confにkernel.unknown_nmi_panic=1を追加する。
1に設定すると、カーネルが未定義のNMIを検出した場合にパニックが発生します。 
参考[4.2.4 カーネル・パニックを制御するパラメータ](https://docs.oracle.com/cd/E77565_01/E54669/html/ol7-panic-params.html)

```:/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)
```