即使文件系統強制檢查失敗，如何允許 SSH 登錄
介紹
我在生產環境中遇到了一些伺服器（CentOS 6.4）的問題，問題是伺服器不時崩潰，我們需要實際重新啟動這些伺服器才能再次使用它們。
問題
問題是，有時在重新啟動後，伺服器會強制檢查文件系統，當它失敗時，有人需要親自到伺服器並手動執行 FSCK。
問題
當強制檢查無法通過 SSH 訪問伺服器時，有沒有辦法實際啟動系統？或者是否有另一種解決方案來定期檢查文件系統和對伺服器的 SSH 訪問。
提前致謝！
首先，使用一些不依賴於作業系統的遠端控制台連接。對於戴爾來說是 iDRAC，對於惠普來說是 iLO，對於 IBM 來說是 RSA2，等等。這是標準做法，因為除了 fsck 之外，您還可能遇到許多其他引導錯誤。
其次，請參閱自動 fsck 問題。但是，如果您正在執行此“自動化”，請確保您已經測試了您的備份。這樣，您的 fsck 將通過，您可以通過 ssh 連接。
我將專注於尋找最初問題的原因。文件系統損壞是機器變得無響應的另一個症狀，或者您正在執行不安全的重新啟動（電源循環），或者兩者兼而有之。
你沒有說你的文件系統是如何排列的以及哪些文件系統正在損壞。如果您有一個非常小的根文件系統，幾乎所有其他內容都作為單獨的掛載（
/sbin,/etc和其他一些東西通常需要保留在根 fs 上）並且正在處理的東西fsck都在非根文件系統上，那麼如果您熟悉使用 shell 腳本，您可以調整引導過程，以便
- 只有問題
/導致它阻塞/在檢查並準備好後儘快啟動 ssh- 如果發現問題，其他文件系統以只讀方式掛載（可能會通過郵件提醒您，並且其他面向公眾的服務未啟動）
這樣你就可以通過 ssh 來修復其他文件系統並啟動干淨的重啟以使事情恢復正常。
有一些選項可以設置
fsck為自動嘗試修復問題（如果它們是由不安全的重啟引起的，大多數情況下通常並不嚴重，尤其是日誌文件系統），但通常不建議在生產環境中這樣做，因為它可以隱藏日益嚴重的問題。在 Debian/Ubuntu/similar 中查找FSCKFIX選項，如果是在已成功安裝讀寫的文件系統上/etc/default/rcS，則結果會登錄- CentOS 中也將存在類似的東西。/var/log/fsck/checkfs``/var如果你真的想穩操勝券，請將（最後一列）
pasnum中的所有內容設置為/etc/fsck0，並且不會檢查任何內容。*這當然是非常不推薦的…*如果您確實採用這種方法，我建議您將最小服務設置為在啟動時自動啟動，重新啟動後立即啟動 SSH，在fsck以只讀方式安裝時手動執行所有內容，重新安裝所有內容+write 模式，然後啟動您的服務（這樣您可以訪問機器，但在您確定機器上的文件系統是乾淨的之前，您的面向使用者的服務不會啟動）。但真正找到根本原因應該是您在 IMO 的首要任務，遠端 KVM 選項比冒險引導到具有潛在損壞文件系統的作業系統更好。