☰

自发重启后无法退出救援模式

tag-icon • tag-icon linux networking centos iptables
自发重启后无法退出救援模式

我遇到了一个奇怪的问题，我使用的 CentOS 6.5 系统在未经我授权的情况下自动重启，然后进入救援模式，我无法进一步诊断问题。

这个服务器是新服务器，这也是我最初感到困惑的原因之一。这种情况发生了两次，第二次，我记录了我的所有操作，以查看是否存在我造成的潜在问题。

当我以 root 用户身份登录时，我的流程如下：

  1. yum update
  2. 安装 EPEL 后，fail2ban
  3. 创建deploy用户useradd
  4. authorized_keys使用我的 RSA 公钥和其他人密钥建立一个文件
  5. 更改的权限：
    • chmod 700 /home/deploy/.ssh
    • chmod 400 /home/deploy/.ssh/authorized_keys
  6. 已更改密码root并deploy已将其添加deploy到 sudoers 列表（visudo）
  7. 更改了以下几行sshd_config：
    • PermitRootLogin no
    • PasswordAuthentication no
    • AllowUsers deploy
  8. 更改的iptables配置：
    • iptables -P INPUT ACCEPT
    • iptables -F
    • iptables -A INPUT -i lo -j ACCEPT
    • iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    • iptables -A INPUT -p tcp --dport 22 -j ACCEPT
    • iptables -P INPUT DROP
    • iptables -P FORWARD DROP
    • iptables -P OUTPUT ACCEPT
    • iptables -A INPUT -p tcp --dport 80 -j ACCEPT
    • iptables -A INPUT -p tcp --dport 21 -j ACCEPT
    • service iptables save
    • service iptables restart

据我所知，到目前为止我所做的一切都是正确的程序。当我继续创建一些 MySQL 数据库时，我突然收到了以下输出：

Broadcast message from [email protected]
    (unknown) at 2:22 ...

The system is going down for reboot NOW!
Control-Alt-Delete pressed 
Connection to 192.99.10.69 closed by remote host.
Connection to 192.99.10.69 closed.

这不仅让我措手不及，我还在思考这怎么可能发生，因为当时我是唯一连接到服务器的用户，而且我正在 MySQL 命令提示符中创建用户。我确信我没有按下键盘上的 CTRL+ALT+DEL。

在此之后，服务器提供商 SoYouStart 给我发来标准电子邮件，通知我服务器已进入救援模式。进入救援模式后，我参考本指南作为我如何诊断问题的参考。我最初用 找出我的硬盘分区fdisk -l。此服务器使用软件 RAID，较大的 RAID 分区位于md3分区上。

因此，我尝试运行fsck /dev/md3以查看文件系统是否存在问题，但无法解决。我还尝试对硬盘进行 SMART 测试，它们都通过了，没有任何重大错误。

随后，我使用驱动器挂载了驱动器mount /dev/md3 /mnt/md3，并尝试进入文件系统。我尝试编辑rc.local文件并添加了这个（来源)：

#!/bin/sh -e
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT

此后，只需reboot将系统重新置于救援模式即可。

我不知道到底发生了什么。我不确定这是用户错误还是其他原因。我在许多其他服务器上执行过此过程，包括同一提供商的不同专用服务器，但我不知道是什么原因导致的。

答案1

我猜是你的服务器提供商在负责。他们似乎正在向你的服务器发送 acpi 事件以重新启动。这可能是他们对禁用 ssh 密码授权、ssh 密钥更改或密码更改的反应，他们延迟检测到了这些情况。

相关内容