[救援記事] EC2 buntu 20.04 - systemd-udev-trigger.service: Failed to adjust resource limit RLIMIT_NOFILE: Operation not permitted

*心得: 好累，以後要切記進行系統更新前保險的做法是做一個快照

前言: 這是公司的一台測試區的環境，Ubuntu 20.04 LTS，這一台從開始就是公司讓我去建置的，所以我大概五至十天就會上來刷更新，但就在最近，有 intel-microcode, libc-bin, libc-dev-bin, libc6, libc6-dev, libtss2-esys0, locales, ubuntu-advantage-tools, ubuntu-pro-client, ubuntu-pro-client-l10n 列出要更新，所以我一如往常的就進行更新，然後因為 intel-microcode 的關係，所以會需要重開機，但我進行重開機之後就再也連不到了

狀況: 重開機後我 ssh 就一直連不到，而且重點是發生在半夜…沒辦法，我只能先向老闆報告，也說明我更新的操作是一直以來就有，但唯獨這次有狀況…我跟老闆借了公司的 aws console 的帳號，登入進去後，在 instance>> 那看到測試的狀況是 "running"，但是…在檢查執行狀況那邊是 1/2 的情況，而且這個時候已經不能用 aws console 提供的 web connection 連到主機中

所以先看 aws console 的提供的系統日誌，因為 web 版的系統日誌中帶有一些奇怪的亂碼，但在可讀的資料中已經有發現不少 "failed to start...", "failed to mount..." 訊息，所以想到把測試機的 EBS 給 detach，然後再 attach 到 Rescue 的 instance 中，來檢查一下

救援操作

1. ssh 進入 Rescue instance
2. sudo mount /dev/xvdf1 /mnt/recovery
• xvdf1 是我自己編的，這個請以實際情況下的代號為主
3. sudo chroot /mnt/recovery
4. cat /var/log/syslog | more
• 翻到發生問題的時間，看看當時開機的記錄
5. 找到第一個出現 Failed 或類似錯誤、啟動失敗的訊息，在我的狀況中，我第一個出現的是 `systemd-udev-trigger.service: Failed to adjust resource limit RLIMIT_NOFILE: Operation not permitted`
6. 看到 RLIMIT_NOFILE 時，我就想到在這次更新之前，我因為在優化 mysql 的關係，有在以下兩個檔案處加了東西
• /etc/sysctl.conf: `我在最後加上了 `fs.file-max = 102400`
• /etc/sysctl.d/100-custom.conf: 這是新增出來的檔案，裡面只有加上 `fs.nr_open = 102400`
7. 將 `fs.file-max` 和 `fs.nr_open` 先註解掉
8. 退出 chroot(直接 exit)
9. umount /mnt/recovery
10. 退出 Rescue instance
11. 停止 Rescue instance
12. (確定已停止) 將本來 attach 給 Rescue instance 的要救援的 EBS 給 detach，然後再 attach 回原本的 測試機 instance
13. 啟動 測試機 instance
• 啟動正常

上述的狀況看起來花的時間不多，但實際上…這只是我精簡的操作，因為我本來並沒想到跟 RIMIT_NOFILE 有關，因為在看 syslog 時，一開始的注意力被 amazon-ssm-agent 這服務總是出現 404 的紀錄而感到困惑

然後我在還沒想到是 RIMIT_NOFILE 有關前，我都以為是因為做了系統更新的關係，我還想到要修改 grub，或者是把當時更新的套件都退版回去，在都是無效的情況下，又再一次想到真的逐筆的把 syslog 紀錄給看完後才發現 RIMIT_NOFILE 有關

唉，真是手賤