[救援記事] EC2 Ubuntu 20.04 - systemd-journald[xxx]: File /run/log/journal/[...]/system.journal corrupted or uncleanly shut down, renaming and replacing.

前言: 這是公司的一台在未來要做主要的 DB server，幾天前 instance 才創建好，老闆就讓我有空在上面開始佈署相關的軟體跟設定，大至上在前一、兩天就都已經設定好了，因為並沒有急著上線使用，所以就先擺著，然後我也一樣時不時的上去刷系統更新，就前最近，跟前一篇救援記事提到的公司的測試機的狀況一下，系統更新完重開機就連不到了

狀況: 其這一台發生問題的時間比測試機早，這一台是我在上班時間發生的狀況，測試機是同一天的半夜…只不過，aws 的 ebs 只能掛載在同一個「可用區域」的 instance 中，這台 DB instance 的可用區域我老闆建置在別的地方，跟公司原本的可用區域的位置不同，所以一開始我沒辦法把 db 的 ebs 掛到另一個區域的救援機上，所以之前只能先救援測試機

就在凌晨把測試機救援回來就有相對的信心來處理 DB server

救援操作

1. 啟動 DB instance
• 雖然已經知道無法正常啟動，但我主要是要看截圖畫面看卡在哪，跟系統日誌
• 系統日誌大至上和測試機異常時的日誌一樣，但截圖畫面不一樣，測試機卡住的畫面就只有一個游標，但 DB instance 是卡在 `systemd-journald[xxx]: File /run/log/journal/[...]/system.journal corrupted or uncleanly shut down, renaming and replacing.`
2. 停止 DB instance
3. detach DB EBS
4. create Rescue instance
• mini 的規格就行
• 要記得可用區域要和 DB instance 同一個
5. DB EBS attach to Rescue instance
6. ssh 進入 Rescue instance
7. sudo mount /dev/xvdf1 /mnt/recovery
• xvdf1 是我自己編的，請以實際情況下的代號為主
8. sudo chroot /mnt/recovery
9. cd /var/log/journal
• 因為這次的問題，系統並沒有啟動到 syslog 的服務，所以從 syslog 中看不到紀錄
• 會找 journal 主要是因為 `systemd-journald[xxx]: File /run/log/journal/[...]/system.journal corrupted or uncleanly shut down, renaming and replacing.`
10. journalctl -p5
• 直接 cat system.journal 會看不懂，這個檔本身的資料編碼應該是特殊的，所以要透過 journalctl 來看 systemd 的紀錄
• -p: priority, 列出指定等級的紀錄
• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug
11. 看到紅字的異常 `systemd[xxx]: multipathd.service: Failed to adjust resource limit RLIMIT_NOFILE: Operation not permitted`
• 我主要是先看紀錄的時間，因為我還記得重新啟動的時間大概是什麼時候，所以以這個時間來看啟動紀錄中有沒有異常的，而紅字比較明顯
12. 又是熟悉的 RIMIT_NOFILE…
• /etc/sysctl.conf: 沒發現有設定 `fs.file-max` 和 `fs.nr_open`
• /etc/sysctl.d/100-custom.conf: 這是新增出來的檔案，有加上 `fs.nr_open = 102400`
• 我其實本來就有預期應該是和測試機是同一個問題，只是我沒想到的是我在 DB instance 並沒有在 /etc/sysctl.conf 設定 `fs.file-max = 102400`，所以可知這兩次的主因都是 `fs.nr_open`
13. 將 `fs.nr_open` 先註解掉
14. 退出 chroot(直接 exit)
15. umount /mnt/recovery
16. 退出 Rescue instance
17. 停止 Rescue instance
18. (確定已停止) detach DB EBS
19. attach DB EBS 到 DB instance
20. 啟動 DB instance
• 啟動正常

救援 DB server 花的時間就沒有測試機來的久了

呼，好佳在都解決了