Comment dépanner une instance Amazon EC2 qui s'arrête ou se résilie lorsque j'essaie de la démarrer avec l'erreur « InternalError » ou « Client.UserInitiatedShutdown » ?

Brève description

Les causes courantes de l'erreur « InternalError » ou « Client.UserInitiatedShutdown » d'une instance Amazon EC2 sont les suivantes :

• Un volume Amazon Elastic Block Store (Amazon EBS) n'est pas correctement associé à l'instance.
• Un volume EBS attaché à l'instance a un statut de type erreur.
• Un volume EBS chiffré est attaché à l'instance et l'entité n'est pas autorisée à accéder à la clé AWS Key Management Service (AWS KMS).
• Une instance Amazon EC2 a été arrêtée quelques minutes après son démarrage en raison d'une interruption du système d'exploitation telle que le démon d'audit.

Remarque :

• Si votre instance ne démarre pas et qu'aucun code d'erreur n'apparaît, exécutez la commande describe-instances dans l'interface de ligne de commande AWS (AWS CLI). Consultez le message StateReason dans la réponse JSON renvoyée par la commande.
• Si des erreurs surviennent lorsque vous exécutez des commandes AWS CLI, consultez la section Résoudre les erreurs AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Résolution

Les volumes EBS ne sont pas correctement attachés à l'instance

Vous devez associer le volume racine EBS à l'instance sous la forme /dev/sda1 ou /dev/xvda, en fonction du volume défini dans l'API. Vous ne pouvez pas avoir un deuxième volume EBS avec un nom de périphérique dupliqué ou un nom en conflit. Dans ce cas, vous ne pouvez ni arrêter ni démarrer l'instance. Les conflits de noms de périphérique de stockage en mode bloc n'affectent que les types d'instances basés sur Xen (c4, m4, t2, etc.). Les conflits de noms de périphérique de stockage en mode bloc n'affectent pas les instances basées sur Nitro (c5, m5, t3, etc.).

1. Pour vérifier le message d’erreur StateReason et le code d’erreur, exécutez l’API describe-instances:

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

   Remarque : Remplacez us-east-1 par votre région AWS. Remplacez i-nnnnnnnnnnnnnnn par l’ID de votre instance.

   En cas de conflit de nom de périphérique, un message similaire au message suivant s'affiche :

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

2. Ouvrez la console Amazon EC2, puis sélectionnez l'instance que vous ne pouvez pas démarrer.

3. Dans l'onglet Description, vérifiez le nom de périphérique répertorié dans les périphériques de stockage en mode bloc. Le champ des périphériques destockage en mode bloc affiche tous les noms de périphériques des volumes associés.

4. Vérifiez que le périphérique racine est correctement associé et qu'aucun périphérique ne porte le même nom dans la liste ou qu'aucun autre nom n'est en conflit.

5. Si un appareil comporte un doublon ou si le nom de l'appareil est en conflit, détachez d'abord le volume et renommez-le. Rattachez ensuite le volume avec le nom de périphérique mis à jour.

Un volume EBS connecté est en état d'erreur

1. Exécutez l'API describe-instances pour vérifier le message d'erreur et le code d'erreur StateReason :

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

   Remarque : Remplacez us-east-1 par votre région AWS. Remplacez i-nnnnnnnnnnnnnnn par l’ID de votre instance.

   Si un volume EBS connecté présente un état d'erreur, un résultat similaire au message suivant s'affiche :

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

2. Ouvrez la console Amazon EC2, choisissez Volumes, puis vérifiez si l'état du volume est error. Vos options varient selon qu'il s'agit d'un volume racine ou d'un volume secondaire.

3. Si le volume en état d'erreur est un volume secondaire, détachez-le, puis démarrez l'instance.

4. Si le volume en état d'erreur est un volume racine et que vous disposez d'un instantané du volume, procédez comme suit :
   Détachez le volume.
   Créez un nouveau volume à partir de l'instantané.
   Utilisez le nom de périphérique de l'instance d'origine pour attacher le nouveau volume, puis démarrez l'instance.

Remarque : Si aucun instantané du volume racine n'est en état d'erreur, vous ne pouvez pas redémarrer l'instance. Vous devez lancer une nouvelle instance, installer les applications appropriées, puis configurer la nouvelle instance pour remplacer l'ancienne instance.

Les volumes EBS attachés sont chiffrés et les autorisations IAM pour accéder aux clés AWS KMS sont insuffisantes

Pour résoudre ce problème, procédez comme suit pour vérifier les autorisations AWS Identity and Access Management (IAM).

1. Exécutez l'API describe-instances pour vérifier le message d'erreur et le code d'erreur StateReason :

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

   Remarque : Remplacez us-east-1 par votre région AWS. Remplacez i-nnnnnnnnnnnnnnn par l’ID de votre instance.

   Si un volume chiffré est attaché à l'instance et qu'il existe des problèmes d'autorisations ou de politiques, vous recevez un message d'erreur client. Vous obtenez un résultat similaire à l'exemple suivant :

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

Vérifiez que l'utilisateur qui a essayé de démarrer l'instance dispose des autorisations IAM appropriées. Si vous avez lancé l'instance indirectement via un autre service, tel qu'EC2 Auto Scaling, vérifiez également les configurations suivantes :

• La clé AWS KMS utilisée pour chiffrer le volume est activée.
• La clé dispose des bonnes politiques de clé.

Remarque : Pour vérifier si un volume est chiffré, ouvrez la console Amazon EC2, puis sélectionnez Volumes. Les volumes chiffrés affichent l'étiquette Chiffré dans la colonne Chiffrement.

Arrêt de l'instance EC2 en raison de perturbations du système d'exploitation, telles que le démon d'audit

Vérifiez le code d'erreur correspondant à la raison de l'arrêt de l'instance EC2. Si l'instance EC2 s'arrête en raison d'une erreur du système d'exploitation telle que « Client.UserInitiatedShutdown », créez une instance de secours. Suivez ensuite ces étapes de dépannage.

Vérifiez la raison de l'arrêt de l'instance EC2

Pour vérifier pourquoi l'instance EC2 s'est arrêtée, exécutez la commande suivante :

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

Exemple de résultat :

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

Remarque : Il est recommandé de lancer l'arrêt au niveau du système d'exploitation.

Création d’une instance de secours

Suivez ces étapes pour créer une instance de secours. Comme l'instance est arrêtée, vous devez disposer de l'instance de secours pour accéder aux paramètres dans auditd.conf.

1. Ouvrez la console Amazon EC2.

2. Dans le volet de navigation, choisissez Instances, puis sélectionnez l'instance dégradée.

3. Arrêtez l’instance.

4. Détachez le volume Amazon EBS /dev/xvda de l'instance arrêtée.

5. Lancez une nouvelle instance EC2 dans la même zone de disponibilité que l’instance dégradée. La nouvelle instance devient alors votre instance de secours.

6. Attachez le volume racine que vous avez détaché à l’étape 4 à l’instance de secours en tant que périphérique secondaire.

7. Utilisez SSH pour vous connecter à votre instance de secours.

8. Montez le volume sur /mnt à l’aide de la commande suivante :

   $ sudo mount /dev/xvdf /mnt/

   Remarque : Si le répertoire /mnt/var/log est vide ou absent, vérifiez que l'entrée /mnt/etc/fstab existe. Montez ensuite la partition requise pour /var/log ou /var/log/audit en suivant l'étape 8.

Vérifcation des journaux au niveau du système d'exploitation

Pour vérifier les journaux au niveau du système d'exploitation pour le démon d'audit, exécutez les commandes suivantes :

Systèmes d’exploitation basés sur RPM :

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

Systèmes d’exploitation basés sur Debian :

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

Le résultat suivant indique que l'espace disque est insuffisant pour le démon d'audit et que l'instance est arrêtée :

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

Habituellement, une partition différente est montée pour /var/log ou /var/log/audit, et ces partitions sont pleines alors que la partition racine est libre d'espace disque. Dans ce scénario, l'erreur « No space left on device » ne se produit pas, mais l'instance ne démarre pas.

Vérification de l'espace disque

Pour vérifier l'espace disque, exécutez la commande suivante :

> df -hT

Vérification des paramètres d'action du démon d'audit

Si l'espace disque est plein, vérifiez l'action du démon d'audit sous /etc/auditd/auditd.conf pour les paramètres suivants :

admin_space_left

Cette valeur définit la valeur minimale en mégaoctets du disque libre pour que le démon d'audit puisse effectuer une action en cas d'espace disque insuffisant.

admin_space_left_action

Ce paramètre définit l'action que le démon d'audit exécute lorsque l'espace disque est insuffisant. Les valeurs valides sont ignore, syslog, rotate, email, exec, suspend, single et halt.

Après avoir modifié l'action du démon d'audit, rattachez le volume Amazon EBS à l'instance sous le nom /dev/sda1, puis démarrez l'instance.

Pour plus d'informations sur la façon de modifier ces paramètres, consultez auditd.conf sur le site web de man7.

Remarque : Vous pouvez également augmenter la taille de la partition du volume Amazon EBS.

Informations connexes

Pourquoi ne puis-je pas démarrer ou lancer mon instance EC2 ?

Politiques clés dans AWS KMS

Mise hors service immédiate de l’instance