Amazon SSM Agentを使ってEC2インスタンスに安全に接続している。Amazon SSM Agentはaws.amazon.comのウェブコンソールからEC2インスタンスコンソールに接続することもできる。これが私の好みの方法だ。

数日前、Amazon SSM Agent経由でEC2に接続しようとしたところ応答がなく、その後通常の方法、つまりSSHで接続することにした。

もちろん、まず最初にAmazon SSM Agentを再起動しようとしたところ、以下の表示が出た:

[root@i-0cd9514c60d532e78 ~] systemctl restart amazon-ssm-agent.service
Error: No space left on device

ディスク状態に関するこのエラーメッセージは予想外だった。ディスク使用量を確認してみることにした:

[root@i-0cd9514c60d532e78 ~] df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 960M 0 960M 0% /dev
tmpfs 978M 0 978M 0% /dev/shm
tmpfs 978M 420K 978M 1% /run
tmpfs 978M 0 978M 0% /sys/fs/cgroup
/dev/nvme0n1p1 8.0G 2.6G 5.5G 32% /
tmpfs 196M 0 196M 0% /run/user/1000

おっと！このエラーメッセージはディスク使用量に関するものではないようだが、確認する必要がある。今度はinodeをチェックする:

[root@i-0cd9514c60d532e78 ~] df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
devtmpfs 245750 304 245446 1% /dev
tmpfs 250254 2 250252 1% /dev/shm
tmpfs 250254 388 249866 1% /run
tmpfs 250254 16 250238 1% /sys/fs/cgroup
/dev/nvme0n1p1 4193216 67672 4125544 2% /
tmpfs 250254 1 250253 1% /run/user/1000

inodeでもないことが確認できたのでさらに調査したところ、この同じ問題について既知のバグレポートが存在することがわかった。systemctlの"start"、"stop"、"reload"アクションで「No space left on device」エラーが表示されるが、"enable"、"disable"、"kill"アクションでは発生しないというものだ。バグレポートによると、このエラーはinotifyの"max_user_watches"制限の結果として発生する。inotifyには変更を監視できるファイルとディレクトリの数に制限がある。エラーを解消するには、"/proc/sys/fs/inotify/max_user_watches"の値を増やして、より多くのファイルとディレクトリを追加して変更監視できるようにする必要がある。

リアルタイムで値を変更するには以下を実行する:

echo 1048576 > /proc/sys/fs/inotify/max_user_watches

再起動または停止/開始アクションの後もこの増加した値を永続的にロードするには:

/etc/sysctl.confに行"fs.inotify.max_user_watches=1048576"を追加する。sysctl -pコマンドでsysctl設定を確認できる。

参考文献:
https://bugzilla.redhat.com/show_bug.cgi?id=894483
https://bugzilla.redhat.com/show_bug.cgi?id=1452933

結論