如何对尝试启动 Amazon EC2 实例时停止或终止并出现“InternalError”或“Client.UserInitiatedShutdown”错误的 Amazon EC2 实例进行故障排除？

简短描述

以下是 Amazon EC2 实例出现“InternalError”或“Client.UserInitiatedShutdown”错误的常见原因：

• Amazon Elastic Block Store（Amazon EBS）卷未正确附加到实例。
• 附加到实例的 EBS 卷处于错误状态。
• 加密的 EBS 卷已连接到实例，但实体无权使用 AWS Key Management Service（AWS KMS）密钥。
• Amazon EC2 实例在因审计进程守护程序等操作系统中断而启动几分钟后停止。

注意：

• 如果实例无法启动且未出现错误代码，请在 AWS 命令行界面（AWS CLI）中运行 describe-instances 命令。然后，在 JSON 响应中查看命令返回的 StateReason 消息。
• 如果在运行 AWS CLI 命令时收到错误，请参阅排查 AWS CLI 错误。此外，确保您使用的是最新版本的 AWS CLI。

解决方法

EBS 卷未正确附加到实例

您必须将 EBS 根卷作为 /dev/sda1 或 /dev/xvda（取决于在 API 中定义的内容）附加到实例。不能使用设备名称重复或冲突的第二个 EBS 卷。发生这种情况时，不能停止或启动实例。块设备名称冲突仅影响基于 Xen 的实例类型（c4、m4、t2 等）。块设备名称冲突不会影响基于 Nitro 的实例（c5、m5、t3 等）。

1. 要验证 StateReason 错误消息和错误代码，请运行 describe-instances API：

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   **注意：**请将 us-east-1 替换为您的 AWS 区域。将 i-nnnnnnnnnnnnnnn 替换为您的实例 ID。

   如果存在设备名称冲突，则会看到类似于以下消息的输出：

   [    [{
           "StateReason": {
               "Code": "Server.InternalError",
               "Message": "Server.InternalError: Internal error on launch"
           }
       }]
   ]

2. 打开 Amazon EC2 控制台，然后选择无法启动的实例。

3. 在描述选项卡上，验证块设备中列出的设备名称。“块设备”字段显示附加卷的所有设备名称。

4. 确认根设备已正确附加，并且列出的设备没有同名也没有名称冲突。

5. 如果设备有重复或设备名称有冲突，请先分离该卷，然后将其重命名。然后，使用更新的设备名称重新附加该卷。

附加的 EBS 卷处于错误状态

1. 运行 describe-instances API 以验证 StateReason 错误消息和错误代码：

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   **注意：**请将 us-east-1 替换为您的 AWS 区域。将 i-nnnnnnnnnnnnnnn 替换为您的实例 ID。

   如果附加的 EBS 卷处于错误状态，则会收到类似于以下消息的输出：

   [    [{
           "StateReason": {
               "Code": "Server.InternalError",
               "Message": "Server.InternalError: Internal error on launch"
           }
       }]
   ]

2. 打开 Amazon EC2 控制台，选择卷，然后验证卷的状态是否为错误。具体选项取决于相应的卷是根卷还是辅助卷。

3. 如果处于错误状态的卷是辅助卷，请分离该卷，然后启动实例。

4. 如果处于错误状态的卷是根卷，并且您有该卷的快照，请完成以下步骤：
   分离该卷。
   根据快照创建新卷。
   使用原始实例的设备名称附加新卷，然后启动该实例。

**注意：**如果处于错误状态的根卷目前没有快照，则无法重启实例。您必须启动新实例，安装相关应用程序，然后配置新实例以替换旧实例。

附加的 EBS 卷已加密，没有足够的 IAM 权限访问 AWS KMS 密钥

要解决此问题，请按照以下步骤检查 AWS Identity and Access Management（IAM）权限。

1. 运行 describe-instances API 以验证 StateReason 错误消息和错误代码：

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   **注意：**请将 us-east-1 替换为您的 AWS 区域。将 i-nnnnnnnnnnnnnnn 替换为您的实例 ID。

   如果有加密卷附加到该实例并且存在权限或策略问题，则会收到客户端错误。您将看到类似于下面消息的输出：

   [    [{
           "StateReason": {
               "Code": "Client.InternalError",
               "Message": "Client.InternalError: Client error on launch"
           }
       }]
   ]

验证尝试启动实例的用户是否具有相应的 IAM 权限。如果您通过其他服务（例如 EC2 自动扩缩）间接启动了实例，则还要验证以下配置：

• 用于加密卷的 AWS KMS 密钥已激活。
• 密钥具有相应的密钥策略。

注意：要验证卷是否已加密，请打开 Amazon EC2 控制台，然后选择卷。加密卷在加密列中显示已加密标签。

由于审计进程守护程序等操作系统中断，EC2 实例关闭

验证 EC2 实例关闭原因错误代码。如果 EC2 实例因操作系统错误（例如“Client.UserInitiatedShutdown”）而关闭，则创建一个救援实例。然后，按照以下故障排除步骤进行操作。

验证 EC2 实例关闭的原因

要验证 EC2 实例关闭的原因，请运行以下命令：

aws ec2 describe-instances --instance-ids i-xxxx --query 'Reservations[*].Instances[].StateReason'

输出示例：

[
    {
        "Code": "Client.UserInitiatedShutdown",
        "Message": "Client.UserInitiatedShutdown: User initiated shutdown"
    }
]

**注意：**最佳做法是从操作系统层面进行关闭。

创建救援实例

按照以下步骤创建救援实例。由于该实例已停止，因此必须使用救援实例才能访问 auditd.conf 中的参数。

1. 打开 Amazon EC2 控制台。

2. 从导航窗格中选择实例，然后选择受损实例。

3. 停止实例。

4. 从停止的实例中分离 Amazon EBS 卷 /dev/xvda。

5. 在受损实例所在的可用区中启动新的 EC2 实例。该新实例将成为您的救援实例。

6. 将您在第 4 步中分离的 Amazon EBS 卷作为辅助设备附加到救援实例。

7. 使用 SSH 连接到您的救援实例。

8. 使用以下命令将卷挂载到 /mnt：

   $ sudo mount /dev/xvdf /mnt/

   **注意：**如果 /mnt/var/log 目录为空或缺失，请验证 /mnt/etc/fstab 条目是否存在。然后，按照步骤 8 安装 /var/log 或 /var/log/audit 所需的分区。

验证操作系统级别日志

要验证审计进程守护程序的操作系统级别日志，请运行以下命令：

基于 RPM 的操作系统：

> cat /var/log/messages | grep -i "Audit daemon"

基于 Debian 的操作系统：

> cat /var/log/syslog | grep -i "Audit daemon"

以下输出表明审计进程守护程序可用的磁盘空间不足，并且该实例已停止：

auditd[1009]: Audit daemon is low on disk space for logging
auditd[1009]: The audit daemon is now halting the system

通常需要为 /var/log 或 /var/log/audit 安装不同的分区，这些分区变满后，根分区也没有磁盘空间了。在这种情况下，不会出现“No space left on device”错误，但实例无法启动。

验证磁盘空间

要验证磁盘空间，请运行以下命令：

> df -hT

检查审计进程守护程序操作参数

如果磁盘空间已满，请检查 /etc/auditd/auditd.conf 下的审计进程守护程序操作中是否包含以下参数：

admin_space_left

该值定义了审计进程守护程序在磁盘空间不足的情况下执行操作时可用磁盘的最小值（以兆字节为单位）。

admin_space_left_action

此参数定义了审计进程守护程序在磁盘空间不足时执行的操作。有效值包括“忽略”、“系统日志”、“轮换”、“通过电子邮件发送”、“执行”、“暂停”、“单选”和“暂停”。

更改审计进程守护程序操作后，将 Amazon EBS 卷作为 /dev/sda1 附加回实例，然后启动该实例。

有关如何更改这些参数的更多信息，请参阅 man7 网站上的 auditd.conf。

**注意：**您也可以增加 Amazon EBS 卷分区的大小。

相关信息

为什么无法启动 EC2 实例？

AWS KMS 中的密钥策略

实例立即终止