介绍
我在生产环境中遇到了一些服务器（CentOS 6.4）的问题，这个问题导致服务器时不时崩溃，我们需要重新启动这些服务器才能再次使用它们。
问题
问题是，有时重启后服务器会对文件系统执行强制检查，当检查失败时，需要有人亲自前往服务器并手动执行 FSCK。
问题
当强制检查无法通过 SSH 访问服务器时，是否有办法真正启动系统？或者是否有另一种解决方案，既可以定期检查文件系统，又可以通过 SSH 访问服务器。
提前致谢！
答案1
首先，使用一些不依赖于操作系统的远程控制台连接。对于 Dell，它是 iDRAC，对于 HP，它是 iLO，对于 IBM，它是 RSA2，等等。这是标准做法，因为除了 fsck 之外，您还可能遇到许多其他启动错误。
其次，参见自动 fsck 问题。但是，如果您要进行这种“自动化”，请确保您已经测试过您的备份。这样，您的 fsck 就会通过，并且您可以通过 ssh 进行连接。
答案2
我会集中精力寻找最初问题的原因。要么文件系统损坏是机器无响应的另一个症状，要么您正在执行不安全的重启（电源循环），或者以上两种情况都有。
你没有说明你的文件系统是如何排列的，以及哪些文件系统正在损坏。如果你有一个非常小的根文件系统，几乎所有其他东西都是单独挂载的（/sbin、/etc，还有一些其他东西通常需要保留在根文件系统上），并且正在恢复的东西fsck在非根文件系统上，那么如果你熟悉 shell 脚本，你可以调整启动过程，以便
- 只有问题才会
/导致阻塞 /检查并准备就绪后，尽快启动 ssh- 如果发现问题，其他文件系统将以只读方式挂载（您可能会收到邮件提醒，并且不会启动其他面向公众的服务）
这样，您就可以通过 ssh 修复其他文件系统，并启动干净重启以恢复正常。
有一些选项可以设置fsck为自动尝试修复问题（如果问题是由不安全的重启引起的，大多数问题通常并不严重，尤其是日志文件系统），但通常不建议在生产环境中使用，因为它可能会隐藏日益严重的问题。在 Debian/Ubuntu/similar 下查找FSCKFIX中的选项，如果是成功以读写方式挂载的文件系统/etc/default/rcS，结果就会被记录下来- CentOS 中也存在类似的东西。/var/log/fsck/checkfs/var
如果你真的想要凭直觉行事，将（最后一列）pasnum的所有内容都设置/etc/fsck为 0，则不会检查任何内容。当然，非常不推荐这样做……如果您确实采用这种方法，我建议您将最少的服务设置为在启动时自动启动，重启后立即通过 SSH 登录，fsck在以只读方式挂载时手动运行所有内容，以读写模式重新挂载所有内容，然后启动您的服务（这样您就可以访问机器，但您的面向用户的服务不会启动，直到您确定机器上的文件系统是干净的）。
但在我看来，真正找到根本原因应该是您的首要任务，而远程 KVM 选项比冒险启动具有潜在损坏文件系统的操作系统更好。
答案3
可以安装滴熊通过 SSH 服务器进入 INITRD，Debian 上最少。在 Centos 上应该也可以做到同样的事情，不过我没有具体的操作指南可以给你提供。
无论如何，您最好采取某种带外管理设置。