自发重启后无法脱离救援模式

Question

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

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

我的进程以登录到根用户的方式开始：

1. yum update
2. 安装了EPEL和它，fail2ban
3. 用deploy创建用户useradd
4. 用我的RSA密钥和其他人的密钥设置一个authorized_keys文件
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 root@ns4010568.ip-192-99-10.net
    (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来查看文件系统是否有问题无法解决。我还试着在硬盘上做一个智能测试，它们都通过了测试，没有出现任何重大错误。

在此之后，我使用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只会使系统恢复到救援模式。

我不知道可能会发生什么。我不确定是用户错误还是其他原因。我已经在许多其他服务器上完成了这个过程，包括使用同一个提供者的不同的专用服务器，但是我已经没有选择可能导致此过程的原因了。

Answer 1

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