EC2 인스턴스에 안전하게 연결하기 위해 Amazon SSM Agent를 사용하고 있다. 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도 아니라는 것을 확인한 후 추가 조사를 했고, "start", "stop", "reload"의 systemctl 작업은 "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

결론