Comment résoudre l'erreur « Failed to receive X resource signal(s) within the specified duration » (Échec de réception du ou des signaux de ressource X dans le délai imparti) dans AWS CloudFormation ?

Brève description

Cette erreur s'affiche lorsque CloudFormation ne reçoit aucun signal de réussite pour les ressources dont l'attribut CreationPolicy est spécifié avec un ResourceSignal. L'erreur peut se produire pour une instance Amazon EC2, un groupe Auto Scaling ou une condition AWS::CloudFormation::WaitCondition.

Remarque : La résolution suivante s'applique uniquement aux piles CloudFormation que vous créez avec des instances Linux. Pour les instances Windows, consultez la page Comment résoudre l'erreur « Failed to receive X resource signal(s) within the specified duration » pour des instances EC2 Windows dans AWS CloudFormation ?

Résolution

En fonction de votre cas d'utilisation, suivez les étapes de dépannage ci-dessous pour résoudre votre problème.

Remarque : Pour éviter une restauration de la pile, sélectionnez Conserver les ressources correctement allouées pour les options d’échec de la pile dans la console CloudFormation. Cette option signifie qu'une restauration ne sera pas déclenchée en cas d'échec et que l'instance ne sera pas interrompue tant que vous n'aurez pas supprimé la pile.

Le script cfn-signal n'est pas installé sur l'instance de la pile CloudFormation

Pour vérifier que le script cfn-signal est installé sur l'instance configurée pour envoyer des signaux à la pile, procédez comme suit :

1. Utilisez le protocole SSH pour vous connecter à votre instance Linux.
2. Utilisez l'un des scripts suivants pour confirmer que le script cfn-signal est bien installé.
   Pour confirmer la présence du script cfn-signal dans votre répertoire, exécutez la commande suivante :

   $ sudo find / -name cfn-signal/opt/aws/bin/cfn-signal/opt/aws/apitools/cfn-init-1.4-30.amzn2/bin/cfn-sign

   Pour vérifier que le package de scripts d'assistance CloudFormation qui contient le script cfn-signal est bien installé, exécutez la commande suivante :

   $ sudo rpm -q aws-cfn-bootstrapaws-cfn-bootstrap-1.4-30.amzn2.noarch

   Important : La commande présentée ci-dessus fonctionne uniquement sur les distributions qui utilisent le gestionnaire de packages RPM (RPM). Pour plus d'informations sur le gestionnaire de packages RPM, consultez Chapitre 1. Présentation de RPM sur le site Web de Red Hat. Par défaut, les scripts d'assistance CloudFormation sont installés sur des Amazon Machine Images (AMI) Amazon Linux. Pour installer les scripts d'assistance, consultez la page Documentation de référence des scripts d'assistance CloudFormation.

Le modèle CloudFormation contient des erreurs de syntaxe ou des valeurs incorrectes

Pour identifier les erreurs et les valeurs incorrectes, procédez comme suit :

1. Dans un éditeur de code, ouvrez le modèle de votre pile. Recherchez ensuite la section relative à la propriété UserData.
2. Vérifiez les erreurs de syntaxe, les espaces manquants, les fautes d'orthographe et autres fautes de frappe.
3. Vérifiez que les valeurs des propriétés de pile, de ressource et de région AWS sont correctes.
   Remarque : Vérifiez le script bootstrap qui est inclus dans la propriété UserData. Ce script appelle cfn-signal. Vérifiez qu'il ne contient pas d'erreurs de syntaxe ou de valeurs incorrectes.

Si vous signalez dans les commandes cfn-init, recherchez des informations sur le signal dans les journaux cfn-init. Pour rechercher des erreurs dans les journaux cloud-init ou cfn-init, utilisez le protocole SSH pour vous connecter à votre instance. Puis, utilisez le mot clé erreur ou échec pour rechercher des messages d'erreur ou d'échec détaillés dans les journaux suivants :

/var/log/cloud-init-output.log
/var/log/cloud-init.log
/var/log/cfn-init.log
/var/log/cfn-init-cmd.log
/var/log/cfn-wire.log

Pour analyser tous les mots erreur ou échec dans les fichiers /var/log/cfn ou /var/log/cloud-init, exécutez la commande suivante :

grep -ni 'error\|failure' $(sudo find /var/log -name cfn\* -or -name cloud-init\*)

Remarque : La commande présentée ci-dessus renvoie le nom du fichier, le numéro de ligne et le message d'erreur.

La valeur de la propriété timeout pour l'attribut CreationPolicy est trop faible

L'attribut CreationPolicy définit la valeur de la propriété délai d’attente. Vérifiez que la valeur est suffisamment élevée pour exécuter des tâches avant que le script cfn-signal n'envoie des signaux aux ressources CloudFormation.

Pour vérifier la valeur de la propriété délai d’expiration et comparer les horodatages de signalisation et de défaillance des ressources, procédez comme suit :

1. Dans un éditeur de code, ouvrez le modèle CloudFormation pour votre pile afin de trouver la valeur de la propriété délai d’expiration.
   Remarque : La valeur de la propriété timeout indique la durée d’attente maximale du signal par CloudFormation avant l’envoi d’une erreur.
2. Pour estimer le moment de l’activation du script cfn-signal, utilisez SSH pour vous connecter à l'instance. Exécutez ensuite la commande suivante :

   less /var/log/cfn-init.log

   Le fichier journal affiche un horodatage lorsque le signal RÉUSSITE est envoyé aux ressources CloudFormation.
3. Ouvrez la console CloudFormation.
4. Choisissez la vue Événements.
5. Sélectionnez Motif du statut. Développez la ligne correspondant à l'événement avec le motif du statut « Impossible de recevoir le ou les signaux de ressources X au cours de la durée spécifiée. »
6. Comparez l'horodatage du signal à l'horodatage de défaillance des ressources.
   Remarque : Pour réussir l’exécution, le script doit envoyer le signal avant la création ou l’échec de l'instance.

Le cfn-signal n'est pas envoyé depuis l'instance

Vérifiez que le signal reçu par CloudFormation provient de l'instance. Consultez le journal des connexions cfn disponible dans /var/log/cfn-wire.log. Si la réponse n'est pas 200, il se peut qu'il y ait un problème de connectivité entre votre instance et le point de terminaison de CloudFormation.

Lorsque vous envoyez des signaux depuis un emplacement qui n'est pas votre instance, utilisez l'API SignalResource. Par exemple, vous pouvez utiliser une fonction AWS Lambda pour appeler l'API SignalResource, puis envoyer le signal à la pile. Si une erreur s’affiche, utilisez CloudWatch Logs pour consulter vos journaux Lambda afin de comprendre pourquoi le signal n'a pas été envoyé à la pile.