Wie behebe ich eine Amazon EC2-Instance, die stoppt oder beendet wird, wenn ich versuche, sie mit dem Fehler „InternalError“ oder „Client.UserInitiatedShutdown“ zu starten?

Kurzbeschreibung

Die folgenden Gründe sind häufige Ursachen für einen Amazon EC2-Instance-Fehler „InternalError“ oder „Client.UserInitiatedShutdown“:

• Ihr Amazon Elastic Block Store (Amazon EBS)-Volume ist nicht korrekt an die Instance angehängt.
• Ein EBS-Volume, das an die Instance angehängt ist, befindet sich in einem Fehlerzustand.
• Ein verschlüsseltes EBS-Volume ist an die Instance angehängt und die Entität hat keine Berechtigungen für den AWS Key Management Service (AWS KMS)-Schlüssel.
• Eine Amazon EC2-Instance wurde einige Minuten nach ihrem Start durch eine Betriebssystemstörung wie den Audit-Daemon gestoppt.

Anmerkung:

• Wenn Ihre Instance nicht startet und kein Fehlercode erscheint, führen Sie den Befehl describe-instances in der AWS Command Line Interface (AWS CLI) aus. Überprüfen Sie dann die StateReason-Nachricht, die der Befehl in der JSON-Antwort zurückgibt.
• Wenn Sie beim Ausführen von Befehlen in AWS CLI Fehlermeldungen erhalten, finden Sie weitere Informationen unter Beheben von AWS CLI-Fehlern. Stellen Sie außerdem sicher, dass Sie die neueste Version von AWS CLI verwenden.

Behebung

EBS-Volumes sind nicht korrekt an die Instance angehängt

Sie müssen das EBS-Stamm-Volume als /dev/sda1 oder /dev/xvda an die Instance anhängen, je nachdem, welches Volume in der API definiert ist. Sie können kein zweites EBS-Volume mit einem doppelten Gerätenamen oder einem Namen haben, der Konflikte verursacht. In diesem Fall können Sie die Instance nicht beenden oder starten. Konflikte mit Blockgerätenamen betreffen nur Xen-basierte Instance-Typen (c4, m4, t2, usw.). Konflikte mit Blockgerätenamen wirken sich nicht auf Nitro-basierte Instances aus (c5, m5, t3, usw.).

1. Führen Sie die describe-instances API aus, um die StateReason-Fehlermeldung und den Fehlercode zu überprüfen:

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

   Hinweis: Ersetzen Sie us-east-1 durch Ihre AWS-Region. Ersetzen Sie i-nnnnnnnnnnnnnnn durch Ihre Instance-ID.

   Wenn ein Konflikt von Gerätenamen auftritt, wird eine Ausgabe angezeigt, die der folgenden Meldung ähnelt:

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

2. Öffnen Sie die Amazon-EC2-Konsole und wählen Sie dann die Instance aus, die Sie nicht starten können.

3. Überprüfen Sie auf der Registerkarte Beschreibung den Gerätenamen, der unter Blockgeräte aufgeführt ist. Im Feld Blockgeräte werden alle Gerätenamen der angeschlossenen Volumes angezeigt.

4. Stellen Sie sicher, dass das Stammgerät korrekt angeschlossen ist und dass kein Gerät mit demselben Namen oder einem Namen aufgeführt ist, der Konflikte verursacht.

5. Wenn es ein Gerät mit einem Duplikat oder einem Gerätenamen gibt, der Konflikte verursacht, trennen Sie zuerst das Volume und benennen Sie es um. Schließen Sie dann das Volume mit dem aktualisierten Gerätenamen erneut an.

Ein angeschlossenes EBS-Volume befindet sich in einem Fehlerzustand

1. Führen Sie die API describe-instances aus, um die StateReason-Fehlermeldung und den Fehlercode zu überprüfen:

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

   Hinweis: Ersetzen Sie us-east-1 durch Ihre AWS-Region. Ersetzen Sie i-nnnnnnnnnnnnnnn durch Ihre Instance-ID.

   Wenn ein angeschlossenes EBS-Volume sich in einem Fehlerzustand befindet, wird eine Ausgabe angezeigt, die der folgenden Meldung ähnelt:

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

2. Öffnen Sie die Amazon-EC2-Konsole, wählen Sie Volumes aus und überprüfen Sie dann, ob der Status des Volumes Fehler lautet. Ihre Optionen hängen davon ab, ob es sich bei dem Volume um ein Stamm-Volume oder ein sekundäres Volume handelt.

3. Wenn es sich bei dem Volume, das sich in einem Fehlerstatus befindet, um ein sekundäres Volume handelt, trennen Sie das Volume und starten Sie dann die Instance.

4. Wenn es sich bei dem Volume, das sich in einem Fehlerstatus befindet, um ein Stamm-Volume handelt und Sie über einen Snapshot des Volumes verfügen, gehen Sie wie folgt vor:
   Trennen Sie das Volume.
   Erstellen Sie ein neues Volume aus dem Snapshot.
   Verwenden Sie den Gerätenamen der ursprünglichen Instance, um das neue Volume anzuhängen, und starten Sie dann die Instance.

Hinweis: Wenn Sie über keinen vorhandenen Snapshot des Stamm-Volumes verfügen, das sich in einem Fehlerstatus befindet, können Sie die Instance nicht neu starten. Sie müssen eine neue Instance starten, die entsprechenden Anwendungen installieren und dann die neue Instance so konfigurieren, dass sie die alte Instance ersetzt.

Angehängte EBS-Volumes sind verschlüsselt und die IAM-Berechtigungen für den Zugriff auf AWS-KMS-Schlüssel sind unzureichend

Um dieses Problem zu beheben, folgen Sie diesen Schritten, um die AWS Identity and Access Management (IAM)-Berechtigungen zu überprüfen.

1. Führen Sie die API describe-instances aus, um die StateReason-Fehlermeldung und den Fehlercode zu überprüfen:

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

   Hinweis: Ersetzen Sie us-east-1 durch Ihre AWS-Region. Ersetzen Sie i-nnnnnnnnnnnnnnn durch Ihre Instance-ID.

   Wenn ein verschlüsseltes Volume an die Instance angehängt ist und Probleme mit Berechtigungen oder Richtlinien auftreten, erhalten Sie eine Client-Fehlermeldung. Das Ergebnis ähnelt der folgenden Meldung:

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

Stellen Sie sicher, dass der Benutzer, der versucht hat, die Instance zu starten, über die richtigen IAM-Berechtigungen verfügt. Wenn Sie die Instance indirekt über einen anderen Dienst wie EC2 Auto Scaling gestartet haben, überprüfen Sie auch die folgenden Konfigurationen:

• Der AWS KMS-Schlüssel, der zum Verschlüsseln des Volumes verwendet wird, ist aktiviert.
• Der Schlüssel hat die richtigen Schlüsselrichtlinien.

Hinweis: Um zu überprüfen, ob ein Volume verschlüsselt ist, öffnen Sie die Amazon-EC2-Konsole und wählen Sie dann Volumes aus. Verschlüsselte Volumes haben die Bezeichnung Verschlüsselt in der Spalte Verschlüsselung.

Herunterfahren der EC2-Instance aufgrund von Betriebsstörungen wie dem Audit-Daemon

Überprüfen Sie den Fehlercode für den Grund für das Herunterfahren der EC2-Instance. Wenn die EC2-Instance aufgrund eines Betriebssystemfehlers wie „Client.UserInitiatedShutdown“ heruntergefahren wurde, erstellen Sie eine Rettungs-Instance. Folgen Sie dann diesen Schritten zur Fehlerbehebung.

Überprüfen Sie den Grund für das Herunterfahren der EC2-Instance

Führen Sie den folgenden Befehl aus, um zu überprüfen, warum die EC2-Instance heruntergefahren wurde:

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

Beispielausgabe:

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

Hinweis: Es hat sich bewährt, das Herunterfahren von der Betriebssystemebene aus einzuleiten.

Eine Rettungs-Instance erstellen

Gehen Sie wie folgt vor, um eine Rettungs-Instance zu erstellen. Da die Instance gestoppt ist, benötigen Sie die Rettungs-Instance, um auf Parameter in auditd.conf zugreifen zu können.

1. Öffnen Sie die Amazon-EC2-Konsole.

2. Wählen Sie im Navigationsbereich Instances aus, und wählen Sie dann die beeinträchtigte Instance aus.

3. Stoppen Sie die Instance.

4. Trennen Sie das Amazon EBS-Volume /dev/xvda von der gestoppten Instance.

5. Starten Sie eine neue EC2-Instance in derselben Availability Zone, in der sich die beeinträchtigte Instance befindet. Die neue Instance wird zu Ihrer Rettungs-Instance.

6. Hängen Sie das Amazon EBS-Volume, das Sie in Schritt 4 getrennt haben, als sekundäres Gerät an die Rettungs-Instance an.

7. Verwenden Sie SSH, um eine Verbindung zu Ihrer Rettungs-Instance herzustellen.

8. Hängen Sie das Volume unter /mnt mit dem folgenden Befehl ein:

   $ sudo mount /dev/xvdf /mnt/

   Hinweis: Wenn das Verzeichnis /mnt/var/log leer ist oder fehlt, überprüfen Sie, ob der Eintrag /mnt/etc/fstab existiert. Mounten Sie dann die erforderliche Partition für /var/log oder /var/log/audit, indem Sie Schritt 8 folgen.

Überprüfen Sie die Protokolle auf Betriebssystemebene

Führen Sie die folgenden Befehle aus, um die Protokolle auf Betriebssystemebene für den Audit-Daemon zu überprüfen:

RPM-basierte Betriebssysteme:

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

Debian-basierte Betriebssysteme:

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

Die folgende Ausgabe weist darauf hin, dass der Festplattenspeicher für den Audit-Daemon knapp ist und dass die Instance gestoppt wurde:

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

Normalerweise wird eine andere Partition für /var/log oder /var/log/audit gemountet, und diese Partitionen werden voll, während die Stamm-Partition frei von Festplattenspeicher ist. In diesem Szenario tritt der Fehler "Kein Speicherplatz mehr auf dem Gerät" nicht auf, aber die Instance wird nicht gestartet.

Überprüfen Sie den Speicherplatz

Führen Sie den folgenden Befehl aus, um den Speicherplatz zu überprüfen:

> df -hT

Überprüfen Sie die Aktionsparameter des Audit-Daemons

Wenn der Festplattenspeicher voll ist, überprüfen Sie die Audit-Daemon-Aktion unter /etc/auditd/auditd.conf auf die folgenden Parameter:

admin_space_left

Dieser Wert definiert den Mindestwert in Megabyte für freie Festplatte, damit der Audit-Daemon eine Aktion bei geringem Speicherplatz ausführen kann.

admin_space_left_action

Dieser Parameter definiert die Aktion, die der Audit-Daemon ausführt, wenn der Speicherplatz knapp wird. Die gültigen Werte sind ignore, syslog, rotate, email, exec, suspend, single und halt.

Nachdem Sie die Audit-Daemon-Aktion geändert haben, hängen Sie das Amazon EBS-Volume als /dev/sda1 wieder an die Instance an und starten Sie dann die Instance.

Weitere Informationen zum Ändern dieser Parameter finden Sie unter auditd.conf auf der man7-Website.

Hinweis: Sie können auch die Größe der Amazon EBS-Volume-Partition erhöhen.

Ähnliche Informationen

Warum kann ich meine EC2-Instance nicht starten oder aufrufen?

Wichtige Richtlinien in AWS KMS

Die Instance wird sofort beendet