AWS IoT Greengrass Version 1 est entré dans la phase de durée de vie prolongée le 30 juin 2023. Pour plus d'informations, consultez la politique de AWS IoT Greengrass V1 maintenance. Après cette date, AWS IoT Greengrass V1 ne publiera pas de mises à jour fournissant des fonctionnalités, des améliorations, des corrections de bogues ou des correctifs de sécurité. Les appareils qui fonctionnent AWS IoT Greengrass V1 sous tension ne seront pas perturbés et continueront à fonctionner et à se connecter au cloud. Nous vous recommandons vivement de migrer vers AWS IoT Greengrass Version 2, qui ajoute de nouvelles fonctionnalités importantes et prend en charge des plateformes supplémentaires.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes de AWS IoT Greengrass

Cette section fournit des informations de dépannage et des solutions possibles pour vous aider à résoudre les problèmes liés à AWS IoT Greengrass.

Pour de plus amples informations sur les quotas (limites) AWS IoT Greengrass, veuillez consulter Quotas de service dans la Référence générale d'Amazon Web Services.

Problèmes liés à AWS IoT Greengrass Core

Si le logiciel AWS IoT Greengrass Core ne démarre pas, essayez les étapes générales de résolution des problèmes suivantes :

Effectuez une recherche dans les symptômes et erreurs suivants pour trouver des informations qui vous aideront à résoudre les problèmes liés à un AWS IoT Greengrass noyau.

 

Erreur : le fichier de configuration ne contient pas CaPath le CertPath ou KeyPath. Le processus de démon Greengrass avec [pid = <pid>] a expiré.

Solution : vous pouvez voir cette erreur dans crash.log lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Cela peut se produire si vous exécutez la version 1.6 ou une version antérieure. Effectuez l’une des actions suivantes :

 

Erreur : impossible d'analyser /<greengrass-root>/config/config.json.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Assurez-vous que le fichier de configuration Greengrass utilise un format JSON valide.

Ouvrez config.json (situé dans /greengrass-root/config) et vérifiez le format JSON. Par exemple, assurez-vous que les virgules sont utilisées correctement.

 

Erreur : Une erreur s'est produite lors de la génération de la configuration TLS : ErrUnknown UriScheme

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Assurez-vous que les propriétés de la section crypto du fichier de configuration Greengrass sont valides. Le message d'erreur doit fournir plus d'informations.

Ouvrez config.json (situé dans /greengrass-root/config) et vérifiez la section crypto. Par exemple, les chemins de certificat et de clé doivent utiliser le format d'URI correct et pointer vers l'emplacement correct.

 

Erreur : échec de démarrage de Runtime : impossible de démarrer les composants Worker : le test de conteneur a expiré.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Définissez la propriété postStartHealthCheckTimeout dans le fichier de configuration Greengrass. Cette propriété facultative configure la durée (en millisecondes) pendant laquelle le démon Greengrass attend la fin de la vérification de l'état post-démarrage. La valeur par défaut est de 30 secondes (30000 ms).

Ouvrez config.json (situé dans /greengrass-root/config). Dans l'objet runtime, ajoutez la propriété postStartHealthCheckTimeout et définissez la valeur sur un nombre supérieur à 30000. Ajoutez une virgule si nécessaire pour créer un fichier JSON valide. Par exemple :

  ...
  "runtime" : {
    "cgroup" : {
      "useSystemd" : "yes"
    },
    "postStartHealthCheckTimeout" : 40000
  },
  ...

 

<address>Erreur : échec de l'appel PutLogEvents sur Cloudwatch local, LogGroup :GreengrassSystem//connection_manager, erreur : échec de l'envoi de la demande causé par RequestError : Post http :<path>///cloudwatch/logs/ : dial tcp : getsockopt : connexion refusée, réponse : {}.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Cela peut se produire si vous exécutez AWS IoT Greengrass sur un appareil Raspberry Pi et que la configuration de la mémoire requise n'a pas été effectuée. Pour plus d'informations, consultez cette étape.

 

<region><account-id><function-name><version><file-name>Erreur : Impossible de créer le serveur en raison de : échec du chargement du groupe : chmod/<greengrass-root>/ggc/deployment/lambda/arn:aws:lambda : ::function : :/: aucun fichier ou répertoire de ce type.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Si vous avez déployé un exécutable Lambda sur le noyau, vérifiez les propriétés de la fonction dans le group.json fichier (Handlersitué dans /greengrass-root /ggc/deployment/group). Si le gestionnaire n'a pas le même nom que le fichier exécutable compilé, remplacez le contenu du fichier group.json par un objet JSON vide ({}) et exécutez les commandes suivantes pour démarrer AWS IoT Greengrass :

cd /greengrass/ggc/core/
sudo ./greengrassd start

Ensuite, utilisez l'API AWS Lambda pour mettre à jour le paramètre handler de la configuration de la fonction, publier une nouvelle version de la fonction, et mettre à jour l'alias. Pour de plus amples informations, veuillez consulter Versions et alias des fonctions AWS Lambda.

En supposant que vous ayez ajouté par alias la fonction à votre groupe Greengrass (recommandé), vous pouvez maintenant redéployer votre groupe. (Si ce n'est pas le cas, vous devez pointer vers la nouvelle version ou le nouvel alias de la fonction dans votre définition de groupe et les abonnements avant de déployer le groupe.)

 

Le logiciel AWS IoT Greengrass Core ne démarre pas une fois que vous êtes passé d'une exécution sans conteneurisation à une exécution dans un conteneur Greengrass.

Solution : vérifiez qu'aucune dépendance de conteneur ne manque.

 

Erreur : la taille du dossier spool doit être d'au moins 262 144 octets.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Ouvrez le fichier group.json (situé dans /greengrass-root/ggc/deployment/group), remplacez le contenu du fichier par un objet JSON vide ({}) et exécutez les commandes suivantes pour démarrer AWS IoT Greengrass :

cd /greengrass/ggc/core/
sudo ./greengrassd start

Ensuite, suivez les étapes de la procédure Pour mettre en cache des messages dans le stockage local. Pour la fonction GGCloudSpooler, assurez-vous de spécifier une valeur GG_CONFIG_MAX_SIZE_BYTES supérieure ou égale à 262 144.

 

Erreur : [ERREUR] - Erreur de messagerie cloud : une erreur s'est produite lors de la tentative de publication d'un message. {"errorString": "operation timed out"}

Solution : Cette erreur peut s'afficher dans GGCloudSpooler.log lorsque le noyau Greengrass ne peut pas envoyer de messages MQTT à AWS IoT Core. Cela peut se produire si l'environnement principal a une bande passante limitée et une latence élevée. Si vous exécutez AWS IoT Greengrass version 1.10.2 ou ultérieure, essayez d'augmenter la valeur de mqttOperationTimeout dans le fichier config.json. Si la propriété n'est pas présente, ajoutez-la à l'objet coreThing. Par exemple :

{
  "coreThing": {
    "mqttOperationTimeout": 10,
    "caPath": "root-ca.pem",
    "certPath": "hash.cert.pem",
    "keyPath": "hash.private.key",
    ...
  },
  ...
}

La valeur par défaut est 5 et la valeur minimale est 5.

 

Erreur : container_linux.go:344: starting container process caused "process_linux.go:424: container init caused \"rootfs_linux.go:64: mounting \\\"/greengrass/ggc/socket/greengrass_ipc.sock\\\" to rootfs \\\"/greengrass/ggc/packages/<version>/rootfs/merged\\\" at \\\"/greengrass_ipc.sock\\\" caused \\\"stat /greengrass/ggc/socket/greengrass_ipc.sock: permission denied\\\"\"".

Solution : vous pouvez voir cette erreur dans runtime.log lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Cela se produit si la valeur de umask est supérieure à 0022. Actuellement, pour résoudre ce problème, vous devez affecter à umask la valeur 0022 ou une valeur inférieure. La valeur 0022 accorde à tout le monde l'autorisation de lecture sur les nouveaux fichiers par défaut.

 

Erreur : exécution du démon Greengrass avec le PID : <id-processus>. Certains composants du système n'ont pas pu démarrer. Recherchez les erreurs dans runtime.log.

Solution : vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Recherchez des informations spécifiques sur l'erreur dans runtime.log et crash.log. Pour plus d’informations, consultez Résolution des problèmes liés aux journaux.

 

Le shadow de l’appareil n'est pas synchronisé avec le cloud.

Solution : assurez-vous qu'AWS IoT Greengrass possède les autorisations d'exécution des actions iot:UpdateThingShadow et iot:GetThingShadow et dans le rôle de service Greengrass. Si le rôle de service utilise la stratégie gérée AWSGreengrassResourceAccessRolePolicy, ces autorisations sont incluses par défaut.

veuillez consulter Dépannage des problèmes de temporisation de la synchronisation shadow.

 

ERREUR : impossible d'accepter la connexion TCP. accept tcp [::]:8000: accept4: trop de fichiers ouverts.

Solution : vous pouvez voir cette erreur dans la sortie du script greengrassd. Cela peut se produire si la limite de descripteur de fichier du logiciel AWS IoT Greengrass Core a atteint le seuil défini et doit être augmentée.

Utilisez la commande suivante et redémarrez le logiciel AWS IoT Greengrass Core.

ulimit -n 2048

 

Erreur : erreur d'exécution de Runtime : impossible de démarrer le conteneur lambda. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:50: preparing rootfs caused \\\"permission denied\\\"\"".

Solution : installez AWS IoT Greengrass directement dans le répertoire racine, ou assurez-vous que le répertoire où le logiciel AWS IoT Greengrass Core est installé et ses répertoires parents disposent d'autorisations execute pour tout le monde.

 

Avertissement : [WARN] - [5] GK Remote : Erreur lors de la récupération des données de clé publique ErrPrincipalNotConfigured : la clé privée pour n' MqttCertificate est pas définie.

Solution : AWS IoT Greengrass utilise un gestionnaire courant pour valider les propriétés de tous les mandataires de sécurité. Cet avertissement dans runtime.log est prévu, sauf si vous avez spécifié une clé privée personnalisée pour le serveur MQTT local. Pour plus d’informations, consultez AWS IoT Greengrass principes de sécurité fondamentaux.

 

<account-id><role-name><region>Erreur : autorisation refusée lors de la tentative d'utilisation du rôle arn:aws:iam : :role/ pour accéder à l'URL s3 https ://-greengrass-updates.s3. <region><architecture><distribution-version>.amazonaws.com/core/ /greengrass-core- .tar.gz.

Solution : cette erreur peut s'afficher en cas d'échec d'une mise à jour over-the-air (OTA). Dans la politique de rôle du signataire, ajoutez la cible Région AWS en tant queResource. Le rôle signataire est utilisé pour pré-signer l'URL S3 pour la mise à jour du logiciel AWS IoT Greengrass. Pour plus d'informations, consultez Rôle de signataire d'URL S3.

 

Le AWS IoT Greengrass cœur est configuré pour utiliser un proxy réseau et votre fonction Lambda ne peut pas établir de connexions sortantes.

Solution : En fonction de votre environnement d'exécution et des exécutables utilisés par la fonction Lambda pour créer des connexions, vous pouvez également recevoir des erreurs de temporisation de connexion. Assurez-vous que vos fonctions Lambda utilisent la configuration de proxy appropriée pour se connecter via le proxy réseau. AWS IoT Greengrasstransmet la configuration du proxy aux fonctions Lambda définies par l'utilisateur via http_proxy les variables d'https_proxyenvironnement, no_proxy et. On peut y accéder comme illustré dans l'extrait de code Python suivant.

import os
print(os.environ['http_proxy'])

Utilisez la même casse que la variable définie dans votre environnement, par exemple, http_proxy en minuscules ou HTTP_PROXY en majuscules. Pour ces variables, AWS IoT Greengrass prend en charge les deux possibilités.

 

Le noyau se trouve dans une boucle de connexion-déconnexion infinie. Le fichier runtime.log contient une série continue d'entrées de connexion et de déconnexion.

Solution : cela peut se produire lorsqu'un autre appareil est codé de manière irréversible pour utiliser le nom d'objet principal comme ID client pour les connexions MQTT à AWS IoT. Les connexions simultanées sont identiques Région AWS et Compte AWS doivent utiliser des identifiants clients uniques. Par défaut, le cœur utilise le nom d'objet principal comme ID client pour ces connexions.

Pour résoudre ce problème, vous pouvez modifier l'ID client utilisé par l'autre périphérique pour la connexion (recommandé) ou remplacer la valeur par défaut pour le cœur.

 

Error: unable to start lambda container. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:62: mounting \\\"proc\\\" to rootfs \\\"

Solution : Sur certaines plateformes, cette erreur peut s'afficher runtime.log lorsque vous essayez de AWS IoT Greengrass monter le système de /proc fichiers pour créer un conteneur Lambda. Vous pouvez également voir des erreurs similaires, telles que operation not permitted ou EPERM. Ces erreurs peuvent se produire même si les tests exécutés sur la plateforme par le script du vérificateur de dépendance aboutissent.

Essayez l'une des solutions suivantes :

 

[ERREUR] -erreur d'exécution du runtime : impossible de démarrer le conteneur Lambda. <ggc-path>{"ErrorString » : « Impossible d'initialiser le montage des conteneurs : impossible de masquer la racine de Greengrass dans le répertoire supérieur de superposition : échec de création du périphérique de masque dans le répertoire : le fichier existe »}

Solution : cette erreur peut s'afficher dans le fichier runtime.log en cas d'échec du déploiement. Cette erreur se produit si une fonction Lambda du AWS IoT Greengrass groupe ne peut pas accéder au /usr répertoire dans le système de fichiers du noyau.

Pour résoudre ce problème, ajoutez une ressource de volume local au groupe, puis déployez le groupe. Cette ressource doit :

 

[ERREUR] - Le déploiement a échoué. {"DeploymentID » : <deployment-id>"«, « errorString » : « <pid>échec du processus de test du conteneur avec pid : état du processus du conteneur : état du processus du conteneur : état de sortie 1"}

Solution : cette erreur peut s'afficher dans le fichier runtime.log en cas d'échec du déploiement. Cette erreur se produit si une fonction Lambda du AWS IoT Greengrass groupe ne peut pas accéder au /usr répertoire dans le système de fichiers du noyau.

Vous pouvez confirmer que tel est le cas en vérifiant s'il n'y a GGCanary.log pas d'autres erreurs. Si la fonction Lambda ne peut pas accéder au /usr répertoire, il GGCanary.log contiendra l'erreur suivante :

[ERROR]-standard_init_linux.go:207: exec user process caused "no such file or directory"

Pour résoudre ce problème, ajoutez une ressource de volume local au groupe, puis déployez le groupe. Cette ressource doit :

 

Error: [ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to create overlay fs for container: mounting overlay at /greengrass/ggc/packages/<ggc-version>/rootfs/merged failed: failed to mount with args source=\"no_source\" dest=\"/greengrass/ggc/packages/<ggc-version>/rootfs/merged\" fstype=\"overlay\" flags=\"0\" data=\"lowerdir=/greengrass/ggc/packages/<ggc-version>/dns:/,upperdir=/greengrass/ggc/packages/<ggc-version>/rootfs/upper,workdir=/greengrass/ggc/packages/<ggc-version>/rootfs/work\": too many levels of symbolic links"}

Solution : cette erreur peut s'afficher dans le runtime.log fichier lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Ce problème peut être plus fréquent sur les systèmes d'exploitation Debian.

Pour résoudre ce problème, procédez comme suit :

 

Error: [DEBUG]-Failed to get routes. Discarding message.

Solution : vérifiez les abonnements dans votre groupe et assurez-vous que l'abonnement répertorié dans le message [DEBUG] existe.

 

Error: [Errno 24] Too many open <lambda-function>,[Errno 24] Too many open files

Solution : cette erreur peut s'afficher dans le fichier journal de votre fonction Lambda si la fonction est instanciée StreamManagerClient dans le gestionnaire de fonctions. Nous vous recommandons de créer le client en dehors du gestionnaire. Pour plus d’informations, consultez Utiliser StreamManagerClient pour travailler avec des flux.

 

Erreur : le serveur DS n'a pas pu démarrer l'écoute du socket : listen unix <ggc-path>/ggc/socket/greengrass_ipc.sock : bind : argument non valide

Solution : cette erreur peut s'afficher lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Cette erreur se produit lorsque le logiciel AWS IoT Greengrass Core est installé dans un dossier dont le chemin de fichier est long. Réinstallez le logiciel AWS IoT Greengrass Core dans un dossier dont le chemin de fichier contient moins de 79 octets, si vous n'utilisez pas de répertoire d'écriture, ou 83 octets, si vous utilisez un répertoire d'écriture.

[INFO] (Photocopieur) aws.greengrass. StreamManager: stdout. Causé par : com.fasterxml.jackson.databind. JsonMappingException: l'instant dépasse l'instant minimum ou maximum

Lorsque vous mettez à niveau le logiciel AWS IoT Greengrass principal vers la version v1.11.3, l'erreur suivante peut s'afficher dans les journaux du gestionnaire de flux si le gestionnaire de flux ne démarre pas.

2021-07-16T00:54:58.568Z [INFO] (Copier) aws.greengrass.StreamManager: stdout. Caused by: com.fasterxml.jackson.databind.JsonMappingException: Instant exceeds minimum or maximum instant (through reference chain: com.amazonaws.iot.greengrass.streammanager.export.PersistedSuccessExportStatesV1["lastExportTime"]). {scriptName=services.aws.greengrass.StreamManager.lifecycle.startup.script, serviceName=aws.greengrass.StreamManager, currentState=STARTING}
2021-07-16T00:54:58.579Z [INFO] (Copier) aws.greengrass.StreamManager: stdout. Caused by: java.time.DateTimeException: Instant exceeds minimum or maximum instant. {scriptName=services.aws.greengrass.StreamManager.lifecycle.startup.script, serviceName=aws.greengrass.StreamManager, currentState=STARTING}

Si vous utilisez une version du logiciel AWS IoT Greengrass principal antérieure à la version v1.11.3 et que vous souhaitez passer à une version ultérieure, utilisez une mise à jour OTA pour passer à la version v1.11.4.

GPG error: https://dnw9lb6lzp2d8.cloudfront.net stable InRelease: The following signatures were invalid: EXPKEYSIG 68D644ABD2327D47 AWS Greengrass Master Key

Lorsque vous l'exécutez apt update sur un appareil sur lequel vous avez installé le logiciel AWS IoT Greengrass principal à partir d'un dépôt APT, l'erreur suivante peut s'afficher.

Err:4 https://dnw9lb6lzp2d8.cloudfront.net stable InRelease
  The following signatures were invalid: EXPKEYSIG 68D644ABD2327D47 AWS Greengrass Master Key
Reading package lists... Done                             
W: GPG error: https://dnw9lb6lzp2d8.cloudfront.net stable InRelease: The following signatures were invalid: EXPKEYSIG 68D644ABD2327D47 AWS Greengrass Master Key

Cette erreur se produit car il AWS IoT Greengrass n'est plus possible d'installer ou de mettre à jour le logiciel AWS IoT Greengrass principal à partir du référentiel APT. Pour une exécution réussieapt update, supprimez le AWS IoT Greengrass référentiel de la liste des sources de l'appareil.

sudo rm /etc/apt/sources.list.d/greengrass.list 
sudo apt update

Problèmes de déploiement

Utilisez les informations suivantes pour résoudre les problèmes de déploiement.

 

Votre déploiement actuel ne fonctionne pas et vous souhaitez revenir à un déploiement opérationnel précédent.

Solution : utilisez la AWS IoT console ou AWS IoT Greengrass l'API pour redéployer un déploiement fonctionnel précédent. Cela déploie la version de groupe correspondante sur votre appareil principal.

 

L'erreur 403 Interdit s'affiche dans les journaux lors du déploiement.

Solution : assurez-vous que la politique du AWS IoT Greengrass noyau dans le cloud inclut "greengrass:*" une action autorisée.

 

Une ConcurrentDeployment erreur se produit lorsque vous exécutez la commande create-deployment pour la première fois.

Solution : un déploiement est peut-être en cours. Vous pouvez exécuter get-deployment-status pour voir si un déploiement a été créé. Si ce n'est pas le cas, essayez de recréer le déploiement.

 

Erreur : Greengrass n'est pas autorisé à assumer le rôle de service associé à ce compte, ou erreur : Échec : le rôle de service TES n'est pas associé à ce compte.

Solution : vous pouvez voir cette erreur lorsque le déploiement échoue. Vérifiez qu'un rôle de service Greengrass est actuellement associé à votre rôle Compte AWS dans le service. Région AWS Pour plus d’informations, consultez Gestion du rôle de service Greengrass (interface de ligne de commande) ou Gestion du rôle de service Greengrass (console).

 

Erreur : impossible d'exécuter l'étape de téléchargement dans le déploiement. erreur lors du téléchargement : erreur lors du téléchargement du fichier de définition de groupe :... x509 : le certificat a expiré ou n'est pas encore valide

Solution : vous pouvez voir cette erreur dans runtime.log lorsque le déploiement échoue. Si vous recevez une erreur Deployment failed contenant le message x509: certificate has expired or is not yet valid, vérifiez l'horloge de l'appareil. Les certificats TLS et X.509 fournissent une base sécurisée pour la construction de systèmes IoT, mais ils nécessitent des temps précis sur les serveurs et les clients. Les appareils IoT doivent avoir l'heure correcte (dans les 15 minutes) avant de tenter de se connecter à AWS IoT Greengrass ou à d'autres services TLS qui utilisent des certificats de serveur. Pour plus d'informations, consultez la section Utilisation de l'heure de l'appareil pour valider les certificats de AWS IoT serveur sur l'Internet des objets sur le blog AWS officiel.

 

Le déploiement n'est pas terminé.

Solution : effectuez les opérations suivantes :

 

Erreur : Impossible de trouver les exécutables Java ou Java8, ou erreur : <deployment-id><group-id>échec du déploiement du type NewDeployment pour le groupe Erreur : le travailleur n'a <worker-id>pas pu s'initialiser avec raison La version Java installée doit être supérieure ou égale à 8

Solution : Si le gestionnaire de flux est activé pour le AWS IoT Greengrass noyau, vous devez installer le runtime Java 8 sur le périphérique principal avant de déployer le groupe. Pour de plus amples informations, veuillez consulter la configuration requise pour le gestionnaire de flux. Le gestionnaire de flux est activé par défaut lorsque vous utilisez le flux de travail de création de groupes par défaut dans la AWS IoT console pour créer un groupe.

Ou, désactivez le gestionnaire de flux, puis déployez le groupe. Pour plus d’informations, consultez Configurer les paramètres du gestionnaire de flux (console).

 

Le déploiement n'est pas terminé et runtime.log contient plusieurs entrées « attendre 1 s que le conteneur s'arrête ».

Solution : exécutez les commandes suivantes sur votre terminal principal pour redémarrer le démon AWS IoT Greengrass.

cd /greengrass/ggc/core/
sudo ./greengrassd stop
sudo ./greengrassd start

 

Le déploiement ne se termine pas et runtime.log contient « [ERROR]-Greengrass deployment error: failed to report deployment status back to cloud {"deploymentId": "<deployment-id>", "errorString": "Failed to initiate PUT, endpoint: https://<deployment-status>, error: Put https://<deployment-status>: proxyconnect tcp: x509: certificate signed by unknown authority"} ».

Solution : Cette erreur peut s'afficher dans runtime.log lorsque le noyau Greengrass est configuré pour utiliser une connexion proxy HTTPS et que la chaîne de certificats du serveur proxy n'est pas approuvée sur le système. Pour essayer de résoudre ce problème, ajoutez la chaîne de certificats au certificat d'autorité de certification racine. Le noyau Greengrass ajoute les certificats de ce fichier dans le groupe de certificats utilisé pour l'authentification TLS dans les connexions HTTPS et MQTT avec AWS IoT Greengrass.

L'exemple suivant présente un certificat d'autorité de certification de serveur proxy ajouté au fichier de certificat d'autorité de certification racine :

# My proxy CA
-----BEGIN CERTIFICATE-----
MIIEFTCCAv2gAwIQWgIVAMHSAzWG/5YVRYtRQOxXUTEpHuEmApzGCSqGSIb3DQEK
\nCwUAhuL9MQswCQwJVUzEPMAVUzEYMBYGA1UECgwP1hem9uLmNvbSBJbmMuMRww
... content of proxy CA certificate ...
+vHIRlt0e5JAm5\noTIZGoFbK82A0/nO7f/t5PSIDAim9V3Gc3pSXxCCAQoFYnui
GaPUlGk1gCE84a0X\n7Rp/lND/PuMZ/s8YjlkY2NmYmNjMCAXDTE5MTEyN2cM216
gJMIADggEPADf2/m45hzEXAMPLE=
-----END CERTIFICATE-----

# Amazon Root CA 1
-----BEGIN CERTIFICATE-----
MIIDQTCCAimgF6AwIBAgITBmyfz/5mjAo54vB4ikPmljZKyjANJmApzyMZFo6qBg
ADA5MQswCQYDVQQGEwJVUzEPMA0tMVT8QtPHRh8jrdkGA1UEChMGDV3QQDExBBKW
... content of root CA certificate ...
o/ufQJQWUCyziar1hem9uMRkwFwYVPSHCb2XV4cdFyQzR1KldZwgJcIQ6XUDgHaa
5MsI+yMRQ+hDaXJiobldXgjUka642M4UwtBV8oK2xJNDd2ZhwLnoQdeXeGADKkpy
rqXRfKoQnoZsG4q5WTP46EXAMPLE
-----END CERTIFICATE-----

Par défaut, le fichier de certificat d'autorité de certification racine se trouve dans /greengrass-root/certs/root.ca.pem. Pour rechercher l'emplacement sur votre appareil noyau, vérifiez la propriété crypto.caPath dans config.json.

 

<path>Erreur : <deployment-id><group-id>échec du déploiement du type NewDeployment pour le groupe Erreur : erreur lors du traitement. la configuration du groupe n'est pas valide : 112 ou [119 0] n'ont pas l'autorisation rw sur le fichier :.

Solution : assurez-vous que le groupe propriétaire du répertoire <chemin> dispose des autorisations de lecture et d'écriture sur le répertoire.

 

Erreur : < list-of-function-arns > sont configurés pour s'exécuter en tant que root, mais Greengrass n'est pas configuré pour exécuter les fonctions Lambda avec les autorisations root.

Solution : vous pouvez voir cette erreur dans runtime.log lorsque le déploiement échoue. Assurez-vous que vous avez configuré AWS IoT Greengrass pour autoriser les fonctions Lambda à s'exécuter avec les autorisations root. Modifiez la valeur de allowFunctionsToRunAsRoot in greengrass_root/config/config.json to yes ou modifiez la fonction Lambda pour qu'elle s'exécute en tant qu'autre utilisateur/groupe. Pour plus d’informations, consultez Exécution d'une fonction Lambda en tant que root.

 

Erreur : <deployment-id><group-id>échec du déploiement du type NewDeployment pour le groupe Erreur : erreur de déploiement de Greengrass : impossible d'exécuter l'étape de téléchargement lors du déploiement. erreur lors du traitement : impossible de charger le fichier de groupe téléchargé : UID introuvable sur la base du nom d'utilisateur, UserName : ggc_user : user : unknown user ggc_user.

Solution : Si l'identité d'accès par défaut du AWS IoT Greengrass groupe utilise les comptes système standard, l'ggc_userutilisateur et le ggc_group groupe doivent être présents sur l'appareil. Pour obtenir des instructions qui expliquent comment ajouter l'utilisateur et le groupe, consultez cette étape. Assurez-vous d'entrer les noms exactement comme indiqué.

 

Error: [ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to mask greengrass root in overlay upper dir: failed to create mask device at directory <ggc-path>: file exists"}

Solution : vous pouvez voir cette erreur dans runtime.log lorsque le déploiement échoue. Cette erreur se produit si une fonction Lambda du groupe Greengrass ne peut pas accéder au /usr répertoire dans le système de fichiers du noyau. Pour résoudre ce problème, ajoutez une ressource de volume local au groupe, puis déployez le groupe. La ressource doit :

 

Erreur : échec <deployment-id>du déploiement du type NewDeployment pour le groupe <group-id>Erreur : échec du démarrage du processus : container_linux.go:259 : le démarrage du processus conteneur a provoqué « process_linux.go:250 : running exec setns process for init caused \" wait : no child processes \ "».

Solution : vous pouvez voir cette erreur lorsque le déploiement échoue. Retentez le déploiement.

 

<host-prefix>Erreur : [WARN] -MQTT [client] compose tcp : lookup -ats.iot. <region>.amazonaws.com : aucun hôte de ce type... [ERREUR] -Erreur de déploiement de Greengrass : impossible de signaler l'état du déploiement au cloud... net/http : demande annulée en attendant la connexion (Client.Timeout dépassé pendant l'attente des en-têtes)

Solution : vous pouvez voir cette erreur si vous utilisez systemd-resolved, ce qui active le paramètre DNSSEC par défaut. Par conséquent, de nombreux domaines publics ne sont pas reconnus. Les tentatives d'atteindre le point de terminaison AWS IoT Greengrass ne parviennent pas à trouver l'hôte. Vos déploiements restent donc à l'état In Progress.

Vous pouvez utiliser les commandes et la sortie suivantes pour tester ce problème. Remplacez l'espace réservé à la région dans les points de terminaison par votre. Région AWS

$ ping greengrass-ats.iot.region.amazonaws.com
ping: greengrass-ats.iot.region.amazonaws.com: Name or service not known

$ systemd-resolve greengrass-ats.iot.region.amazonaws.com
greengrass-ats.iot.region.amazonaws.com: resolve call failed: DNSSEC validation failed: failed-auxiliary

Une solution possible consiste à désactiver DNSSEC. Lorsque DNSSEC a pour valeur false, les recherches DNS ne sont pas validées par DNSSEC. Pour plus d'informations, consultez ce problème connu pour systemd.

Pour plus d'informations sur resolved.conf et DNSSEC, exécutez man resolved.conf dans votre terminal.

 

Problèmes de création de groupe ou de fonction

Utilisez les informations suivantes pour résoudre les problèmes liés à la création d'un AWS IoT Greengrass groupe ou d'une fonction Greengrass Lambda.

 

Erreur : votre configuration « IsolationMode » pour le groupe n'est pas valide.

Solution : cette erreur se produit lorsque la valeur IsolationMode dans la section DefaultConfig de function-definition-version n'est pas prise en charge. Les valeurs prises en charge sont GreengrassContainer et NoContainer.

 

Erreur : votre configuration « IsolationMode » pour la fonction avec arn <function-arn>n'est pas valide.

Solution : cette erreur se produit lorsque la valeur IsolationMode de la section <arn-fonction> de function-definition-version n'est pas prise en charge. Les valeurs prises en charge sont GreengrassContainer et NoContainer.

 

Erreur : MemorySize la configuration de la fonction avec arn <function-arn>n'est pas autorisée dans IsolationMode =NoContainer.

Solution : Cette erreur se produit lorsque vous spécifiez une MemorySize valeur et que vous choisissez de l'exécuter sans conteneurisation. Les fonctions Lambda exécutées sans conteneurisation ne peuvent pas être soumises à des limites de mémoire. Vous pouvez soit supprimer la limite, soit modifier la fonction Lambda pour qu'elle s'exécute dans un AWS IoT Greengrass conteneur.

 

Erreur : la configuration Access Sysfs pour la fonction avec arn <function-arn>n'est pas autorisée dans IsolationMode =. NoContainer

Solution : Cette erreur se produit lorsque vous spécifiez true pour AccessSysfs et que vous choisissez de l'exécuter sans conteneurisation. Les fonctions Lambda exécutées sans conteneurisation doivent avoir leur code mis à jour pour accéder directement au système de fichiers et ne peuvent pas être utilisées. AccessSysfs Vous pouvez soit spécifier la valeur false for, AccessSysfs soit modifier la fonction Lambda pour qu'elle s'exécute dans un AWS IoT Greengrass conteneur.

 

Erreur : MemorySize la configuration de la fonction avec arn <function-arn>est requise dans IsolationMode =GreengrassContainer.

Solution : Cette erreur se produit parce que vous n'avez pas spécifié de MemorySize limite pour une fonction Lambda que vous exécutez dans un AWS IoT Greengrass conteneur. Spécifiez une valeur MemorySize pour résoudre l'erreur.

 

Erreur : <function-arn>La fonction fait référence à une ressource <resource-type>dont le type n'est pas autorisé dans IsolationMode =NoContainer.

Solution : Vous ne pouvez pas accéder aux types de S3_Object.Generic_Archive ressources Local.Device Local.Volume ML_Model.SageMaker.JobML_Model.S3_Object,, ou lorsque vous exécutez une fonction Lambda sans conteneurisation. Si vous avez besoin de ces types de ressources, vous devez les exécuter dans un conteneur AWS IoT Greengrass. Vous pouvez également accéder directement aux appareils locaux lorsque vous les exécutez sans conteneurisation en modifiant le code de votre fonction Lambda.

 

Erreur : la configuration d'Execution pour la fonction ayant l'arn <arn-fonction> n'est pas autorisée.

Solution : Cette erreur se produit lorsque vous créez une fonction Lambda système avec GGIPDetector ou GGCloudSpooler que vous avez spécifié IsolationMode ou RunAs configuré. Vous devez omettre les Execution paramètres de cette fonction Lambda du système.

 

Problèmes de détection

Utilisez les informations suivantes pour résoudre les problèmes liés au service de découverte AWS IoT Greengrass.

 

Erreur : l'appareil appartient à un trop grand nombre de groupes, les appareils ne peuvent pas être dans plus de 10 groupes

Solution : il s'agit d'une limitation connue. Un appareil client peut appartenir à un maximum de 10 groupes.

 

Problèmes liés aux ressources de machine learning

Utilisez les informations suivantes pour résoudre les problèmes liés aux ressources de Machine Learning.

 

InvalidML ModelOwner - GroupOwnerSetting est fourni dans la ressource du modèle ML, mais n' GroupOwner GroupPermission est pas présent

Solution : vous recevez cette erreur si une ressource d'apprentissage automatique contient l'ResourceDownloadOwnerSettingobjet mais que la GroupPermission propriété GroupOwner ou la propriété requise n'est pas définie. Pour résoudre ce problème, définissez la propriété manquante.

 

NoContainer La fonction ne peut pas configurer les autorisations lors de l'attachement de ressources Machine Learning. <function-arn>fait référence à une ressource d'apprentissage automatique <resource-id>avec autorisation <ro/rw> dans la politique d'accès aux ressources.

Solution : vous recevez cette erreur si une fonction Lambda non conteneurisée spécifie des autorisations au niveau de la fonction pour une ressource de machine learning. Les fonctions non conteneurisées doivent hériter des autorisations du propriétaire de la ressource définies sur la ressource de Machine Learning. Pour résoudre ce problème, choisissez d'hériter des autorisations du propriétaire des ressources (console) ou de supprimer les autorisations de la politique d'accès aux ressources (API) de la fonction Lambda.

 

<function-arn>La fonction fait référence à une ressource Machine Learning dont l'<resource-id>autorisation est manquante à la fois dans la ressource ResourceAccessPolicy et dans la ressource OwnerSetting.

Solution : vous recevez cette erreur si les autorisations d'accès à la ressource d'apprentissage automatique ne sont pas configurées pour la fonction Lambda attachée ou pour la ressource. Pour résoudre ce problème, configurez les autorisations dans la ResourceAccessPolicypropriété de la fonction Lambda ou dans la OwnerSettingpropriété de la ressource.

 

<function-arn>La fonction fait référence à la ressource Machine Learning <resource-id>avec l'autorisation \ "rw \ », tandis que le paramètre du propriétaire de la ressource autorise GroupPermission uniquement \ "ro \ ».

Solution : vous recevez cette erreur si les autorisations d'accès définies pour la fonction Lambda associée dépassent les autorisations du propriétaire de la ressource définies pour la ressource d'apprentissage automatique. Pour résoudre ce problème, définissez des autorisations plus restrictives pour la fonction Lambda ou des autorisations moins restrictives pour le propriétaire de la ressource.

 

NoContainer La fonction <function-arn>fait référence aux ressources du chemin de destination imbriqué.

Solution : vous recevez cette erreur si plusieurs ressources de machine learning associées à une fonction Lambda non conteneurisée utilisent le même chemin de destination ou un chemin de destination imbriqué. Pour résoudre ce problème, spécifiez des chemins de destination distincts pour les ressources.

 

La fonction Lambda <function-arn> accède à la ressource <resource-id> en partageant le même identifiant de propriétaire de groupe

Solution : vous recevez cette erreur runtime.log si le même groupe de système d'exploitation est spécifié comme identité Run as de la fonction Lambda et propriétaire de la ressource pour une ressource d'apprentissage automatique, mais que la ressource n'est pas attachée à la fonction Lambda. Cette configuration donne à la fonction Lambda des autorisations implicites qu'elle peut utiliser pour accéder à la ressource sans AWS IoT Greengrass autorisation.

Pour résoudre ce problème, utilisez un autre groupe de systèmes d'exploitation pour l'une des propriétés ou associez la ressource d'apprentissage automatique à la fonction Lambda.

Problèmes AWS IoT Greengrass Core dans Docker

Utilisez les informations suivantes pour résoudre les problèmes liés à l'exécution d'un AWS IoT Greengrass noyau dans un conteneur Docker.

 

Erreur : options inconnues : -no-include-email.

Solution : cette erreur peut se produire lorsque vous exécutez la commande aws ecr get-login. Assurez-vous que vous disposez de la dernière version de l'interface de ligne de commande AWS CLI installée (par exemple, exécutez : pip install awscli --upgrade --user). Si vous utilisez Windows et avez installé l'interface de ligne de commande à l'aide du programme d'installation MSI, vous devez répéter le processus d'installation. Pour plus d'informations, consultez la section Installation du AWS Command Line Interface sous Microsoft Windows dans le Guide de AWS Command Line Interface l'utilisateur.

 

Avertissement : IPv4 est désactivé. La mise en réseau ne fonctionnera pas.

Solution : vous pouvez recevoir cet avertissement ou un message similaire lors de l'exécution d'AWS IoT Greengrass sur un ordinateur Linux. Activez le réacheminement réseau IPv4 comme décrit dans cette étape. Le déploiement cloud AWS IoT Greengrass et les communications MQTT ne fonctionnent pas lorsque le réacheminement IPv4 n'est pas activé. Pour plus d'informations, consultez Configurer les paramètres du noyau dans un espace de noms (sysctls) lors de l'exécution dans la documentation Docker.

 

Erreur : Un pare-feu bloque le partage de fichiers entre les fenêtres et les conteneurs.

Solution : vous pouvez recevoir cette erreur ou un message Firewall Detected lors de l'exécution de Docker sur un ordinateur Windows. Ce problème peut également survenir si vous êtes connecté à un réseau privé virtuel (VPN) et que vos paramètres réseau empêchent le montage du lecteur partagé. Dans ce cas, désactivez le VPN et réexécutez le conteneur Docker.

 

Erreur : une erreur s'est produite (AccessDeniedException) lors de l'appel de l' GetAuthorizationToken opération : L'utilisateur : arn:aws:iam : ::user/ <account-id><user-name>n'est pas autorisé à effectuer : ecr : on resource : * GetAuthorizationToken

Vous pouvez recevoir cette erreur lors de l'exécution de la aws ecr get-login-password commande si vous ne disposez pas des autorisations suffisantes pour accéder à un référentiel Amazon ECR. Pour plus d'informations, consultez les exemples de politiques relatives aux référentiels Amazon ECR et l'accès à un référentiel Amazon ECR dans le guide de l'utilisateur Amazon ECR.

 

Erreur : Impossible de créer un conteneur pour le service greengrass : conflit. Le nom du conteneur «/aws-iot-greengrass» est déjà utilisé.

Solution : cela peut se produire lorsque le nom du conteneur est utilisé par un conteneur plus ancien. Pour résoudre ce problème, exécutez la commande suivante afin de supprimer l'ancien conteneur Docker :

docker rm -f $(docker ps -a -q -f "name=aws-iot-greengrass")

 

Erreur : [FATAL] - Échec de la réinitialisation de l'espace de noms de montage du thread en raison d'une erreur inattendue : « opération non autorisée ». Pour maintenir la cohérence, GGC tombe en panne et doit être redémarré manuellement.

Solution : Cette erreur runtime.log peut se produire lorsque vous essayez de déployer une fonction GreengrassContainer Lambda sur un AWS IoT Greengrass cœur exécuté dans un conteneur Docker. Actuellement, seules les fonctions NoContainer Lambda peuvent être déployées sur un conteneur Greengrass Docker.

Pour résoudre ce problème, assurez-vous que toutes les fonctions Lambda sont en NoContainer mode et lancez un nouveau déploiement. Ensuite, lors du démarrage du conteneur, ne montez pas le deployment répertoire existant sur le conteneur Docker AWS IoT Greengrass principal. Au lieu de cela, créez un répertoire deployment vide à sa place et liez-le ou montez-le dans le conteneur Docker. Cela permet au nouveau conteneur Docker de recevoir le dernier déploiement avec des fonctions Lambda exécutées en NoContainer mode.

Pour plus d’informations, consultez Exécution de AWS IoT Greengrass dans un conteneur Docker.

Résolution des problèmes liés aux journaux

Vous pouvez configurer les paramètres de journalisation pour un groupe Greengrass, par exemple s'il faut envoyer les CloudWatch journaux à Logs, les stocker sur le système de fichiers local, ou les deux. Pour obtenir des informations détaillées lors de la résolution des problèmes, vous pouvez temporairement définir le niveau de journalisation sur DEBUG. Les modifications apportées aux paramètres de journalisation prennent effet lorsque vous déployez le groupe. Pour plus d’informations, consultez Configurer la journalisation pour AWS IoT Greengrass.

Sur le système de fichiers local, AWS IoT Greengrass stocke les journaux dans les emplacements suivants. La lecture des journaux sur le système de fichiers requiert des autorisations racine.

Si les journaux sont configurés pour être stockés dans le cloud, utilisez CloudWatch Logs pour afficher les messages des journaux. crash.logse trouve uniquement dans les journaux du système de fichiers sur le périphérique AWS IoT Greengrass principal.

S'il AWS IoT est configuré pour écrire des journaux dans CloudWatch, vérifiez-les si des erreurs de connexion se produisent lorsque des composants du système tentent de se connecter àAWS IoT.

Pour plus d'informations sur la journalisation AWS IoT Greengrass, consultez Surveillance avec les journaux AWS IoT Greengrass.

Résolution des problèmes de stockage

Lorsque le stockage de fichiers local est plein, il se peut que certains composants commencent à tomber en panne :

Vous devez toujours connaître la quantité d'espace libre disponible en local. Vous pouvez calculer l'espace libre en fonction de la taille des fonctions Lambda déployées, de la configuration de journalisation (voirRésolution des problèmes liés aux journaux) et du nombre d'ombres stockées localement.

Messages de résolution des problèmes

Tous les messages envoyés localement dans AWS IoT Greengrass sont envoyés avec QoS 0. Par défaut, AWS IoT Greengrass stocke les messages dans une file d'attente en mémoire. Par conséquent, les messages non traités sont perdus lorsque le noyau Greengrass redémarre (par exemple après un déploiement de groupe ou un redémarrage de l'appareil). Cependant, vous pouvez configurer AWS IoT Greengrass (v1.6 ou version ultérieure) pour mettre les messages en cache dans le système de fichiers afin qu'ils persistent pendant les redémarrages principaux. Vous pouvez également configurer la taille de la file d'attente. Si vous configurez une taille de file d'attente, assurez-vous qu'elle est supérieure ou égale à 262 144 octets (256 Ko). Sinon, AWS IoT Greengrass risque de ne pas démarrer correctement. Pour plus d’informations, consultez File d'attente de messages MQTT pour les cibles cloud.

Vous pouvez également configurer l'appareil principal (noyau) pour établir des sessions persistantes avec AWS IoT. Cela permet au noyau de recevoir des messages envoyés AWS Cloud alors que le noyau est hors ligne. Pour plus d’informations, consultez Sessions persistantes MQTT avec AWS IoT Core.

Dépannage des problèmes de temporisation de la synchronisation shadow

En cas de retard important dans la communication entre un appareil principal Greengrass et le cloud, la synchronisation shadow peut échouer en raison d'un délai d'expiration. Dans ce cas, vous devriez voir des entrées de journal similaires à ce qui suit :

[2017-07-20T10:01:58.006Z][ERROR]-cloud_shadow_client.go:57,Cloud shadow client error: unable to get cloud shadow what_the_thing_is_named for synchronization. Get https://1234567890abcd.iot.us-west-2.amazonaws.com:8443/things/what_the_thing_is_named/shadow: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
[2017-07-20T10:01:58.006Z][WARN]-sync_manager.go:263,Failed to get cloud copy: Get https://1234567890abcd.iot.us-west-2.amazonaws.com:8443/things/what_the_thing_is_named/shadow: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
[2017-07-20T10:01:58.006Z][ERROR]-sync_manager.go:375,Failed to execute sync operation {what_the_thing_is_named VersionDiscontinued []}"

Pour remédier à ce problème, vous pouvez configurer la durée pendant laquelle votre appareil principal attend une réponse de l'hôte. Ouvrez le fichier config.json dans greengrass-root/config et ajoutez un champ system.shadowSyncTimeout avec une valeur de délai d'attente en secondes. Par exemple :

{
  "system": {
    "shadowSyncTimeout": 10
  },
  "coreThing": {
    "caPath": "root-ca.pem",
    "certPath": "cloud.pem.crt",
    "keyPath": "cloud.pem.key",
    ...
  },
  ...
}

La valeur par défaut est de 5 secondes si aucune valeur shadowSyncTimeout n'est spécifiée dans config.json.

Consultez AWS re:Post

Si vous ne parvenez pas à résoudre votre problème à l'aide des informations de résolution de problèmes contenues dans cette rubrique, vous pouvez rechercher des problèmes connexes Résolution des problèmes de AWS IoT Greengrass ou consulter le AWS IoT Greengrasstag sur AWS Re:post ou publier une nouvelle question. Les membres de l'AWS IoT Greengrasséquipe surveillent activement AWS Re:post.