問題描述
虛拟機崩潰, 背景進去截圖這樣的:
且無法ssh遠端登入。裝置重新開機可以進入單使用者，但單使用者狀态也不正常。
問題排查步驟
1、根據問題描述，可以進單使用者，便進單使用者看看，通過進單使用者：
在grub選擇核心界面選中目前核心，按E進入grub添加上rw init=/bin/bash cnotallow=tty0
2、journal | less 檢視日志，發現在是檔案系統有問題
3、使用xfs_repaire -L /dev/mapper/klas-root （使用大L有風險，以後還是少用，因為可能會造成資料丢失，在萬不得已的情況下使用，建議先不加大L修複，如果修複失敗再使用大L嘗試修複）。
4、修複之後 ，還是無法進去。會卡在log界面。
5、然後再用單使用者進去，這個時候檔案系統已經正常，可以挂載上分區。
但通過df -hT 發現根目錄已經滿了，Use%=100，這也是導緻系統無法正常啟用的一個原因。
6、通過du –smh /* 排查到使用最大的目錄是var/log目錄。
繼續進入裡面排查，排查造成根目錄滿的原因。使用du -smh /var/log/*發現在/var/log/ 中有一個檔案cron檔案有32G 異常的大。
7、檢視corn日志檔案裡面的資訊，全部是crontab服務的警告資訊。
問題解決步驟
根據問題分析，找到造成此次虛拟機系統檔案系統損壞，無法正常進入作業系統的原因。為cron日志異常增大，且後續還在持續寫入，造成檔案系統損壞。
先是通過進單使用者xfs_repair修複檔案系統，再是找到造成根分區爆滿的原因為corn日志異常的大。
隻需要将corn日志清空即可：
# cat /dev/null > /var/log/cron 可以清空日志。
清空日志後，再測試重新開機作業系統，系統正常。
問題根因分析
1、檢視cron相關的定時任務：
2、分析兩條定時任務：
第一條：每天的01點運作rsync同步指令，同步到遠端主機中的指定目錄。
-a：-a --archive ：歸檔模式，表示遞歸傳輸并保持檔案屬性。等同于"-rtopgDl"。
-v：-v：顯示rsync過程中詳細資訊。可以使用"-vvvv"擷取更詳細資訊。
-z：-z ：傳輸時進行壓縮提高效率。
-P：-P 選項等效于 --partial --progress。 其目的是更容易為可能被中斷的長傳輸指定這兩個選項。（The -P option is equivalent to --partial --progress. Its purpose is to make it much easier to specify these two options for a long transfer that may be interrupted.）
第二條：每天的23點運作指定腳本。
腳本内容如下：
3、檢視系統message日志：
rsyslogd的日志不斷提示對檔案/var/log/corn寫入錯誤，裝置沒有足夠的空間。這是造成檔案系統損壞的根本原因。
也能看到crond服務的警告報錯日志，此資訊在/var/log/cron檔案中全部都是。
結論：故，造成此次檔案系統損壞的根本原因為：
事件順序：定時任務存在文法或同步問題à不斷在/var/log/cron日志中寫入報錯日志à撐爆根目錄，造成檔案系統損壞。
解決順序：單使用者xfs_repair修複檔案系統à單使用者清除/var/log/cron中的報錯資訊à排查問題根因。
問題相關連結
1、進單使用者：
https://blog.csdn.net/qq_41526779/article/details/122378079
2、xfs_repaire修複檔案系統：
#https://www.cnblogs.com/linkenpark/p/7873202.html