如何對在嘗試啟動時發生「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 Command Line Interface (AWS CLI) 中執行 describe-instances 命令。然後，檢查命令在 JSON 回應中傳回的 StateReason訊息。
• 如果您在執行 AWS CLI 命令時收到錯誤，請參閱對 AWS CLI 錯誤進行疑難排解。此外，請確定您使用的是最新的 AWS CLI 版本。

解決方法

EBS 磁碟區未正確連接至執行個體

必須以 /dev/sda1 或 /dev/xvda 的形式將 EBS 根磁碟區連接至執行個體，具體取決於 API 中定義的磁碟區。不能擁有包含重複裝置名稱或衝突名稱的第二個 EBS 磁碟區。發生此情況時，您將無法停止或啟動執行個體。區塊型儲存裝置名稱衝突只會影響以 Xen 為基礎的執行個體類型（c4、m4、t2 等）。區塊型儲存裝置名稱衝突不會影響以 Nito 為基礎的執行個體（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 區域。使用您的執行個體 ID 取代 i-nnnnnnnnnnnnnnn。

   如果裝置名稱發生衝突，您會看到類似下列訊息的輸出：

   [    [{
           "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 區域。使用您的執行個體 ID 取代 i-nnnnnnnnnnnnnnn。

   如果有連接的 EBS 磁碟區處於錯誤狀態，則您會看到類似下列訊息的輸出：

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

2. 開啟 Amazon EC2 主控台，選擇 磁碟區，然後確認磁碟區狀態是否為錯誤。根據磁碟區是根磁碟區還是輔助磁碟區，您的選項會有所不同。

3. 如果處於錯誤狀態的磁碟區是輔助磁碟區，請卸離該磁碟區，然後啟動執行個體。

4. 如果處於錯誤狀態的磁碟區是根磁碟區，而您擁有該磁碟區的快照，請完成下列步驟：
   卸離磁碟區。
   從快照建立新磁碟區。
   使用原始執行個體的裝置名稱連接新磁碟區，然後啟動執行個體。

**注意：**如果您沒有處於錯誤狀態的根磁碟區的現有快照，則無法重新啟動執行個體。您必須啟動新執行個體、安裝相關應用程式，然後將新執行個體設定為取代舊執行個體。

連接的 EBS 磁碟區已加密，且存取 AWS KMS 金鑰的 IAM 權限不足

若要解決此問題，請遵循下列步驟，檢查 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 區域。使用您的執行個體 ID 取代 i-nnnnnnnnnnnnnnn。

   如果執行個體有連接的加密磁碟區，而且存在權限或政策問題，表示您收到用戶端錯誤訊息。您會看到與下列訊息類似的輸出：

   [    [{
           "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 掛載不同分區，且這些分區將在根分區沒有磁碟空間時變滿。在此情境下，不會發生「裝置上沒有剩餘空間」錯誤，但執行個體也不會啟動。

驗證磁碟空間

若要驗證磁碟空間，請執行以下命令：

> df -hT

檢查稽核常駐程式動作參數

如果磁碟空間已滿，請檢查 /etc/auditd/auditd.conf 下方的稽核常駐程式動作是否具有以下參數：

admin_space_left

此值定義了針對磁碟空間不足執行動作期間，稽核常駐程式可用磁碟的最小值 (以百萬位元組為單位) 。

admin_space_left_action

此參數定義了稽核常駐程式在磁碟空間不足時執行的動作。有效值包括「ignore」、「syslog」、「rotate」、「email」、「exec」、「suspend」、「single」、「halt」。

變更稽核常駐程式動作後，重新將 Amazon EBS 磁碟機以 /dev/sda1 連接至執行個體，然後啟動執行個體。

如需如何變更這些參數的詳細資訊，請參閱 man7 網站上的 auditd.conf。

**注意：**您也可以增加 Amazon EBS 磁碟區分區大小。

相關資訊

為什麼我無法啟動 EC2 執行個體？

AWS KMS 中的金鑰政策

執行個體立即終止