

Avis de fin de support : le 7 octobre 2026, AWS le support de. AWS IoT Greengrass Version 1 Après le 7 octobre 2026, vous ne pourrez plus accéder aux AWS IoT Greengrass V1 ressources. Pour plus d'informations, rendez-vous sur [Migrer depuis AWS IoT Greengrass Version 1](https://docs.aws.amazon.com/greengrass/v2/developerguide/migrate-from-v1.html).

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 AWS IoT Greengrass
<a name="gg-troubleshooting"></a>

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

<a name="gg-limits-genref"></a>Pour plus d'informations sur AWS IoT Greengrass les quotas (limites), consultez la section [Quotas de Service](https://docs.aws.amazon.com/general/latest/gr/greengrass.html#limits_greengrass) dans le *Référence générale d'Amazon Web Services*.

## AWS IoT Greengrass Principaux problèmes
<a name="gg-troubleshooting-coreissues"></a>

Si le logiciel AWS IoT Greengrass Core ne démarre pas, essayez les étapes générales de résolution des problèmes suivantes :
+ Veillez à installer les fichiers binaires appropriés pour votre architecture. Pour plus d'informations, consultez [Logiciel AWS IoT Greengrass Core](what-is-gg.md#gg-core-download-tab).
+ Assurez-vous que votre appareil principal dispose d'un stockage local disponible. Pour de plus amples informations, veuillez consulter [Résolution des problèmes de stockage](#troubleshooting-storage).
+ Recherchez les éventuels messages d'erreur dans `runtime.log` et `crash.log`. Pour de plus amples informations, veuillez consulter [Résolution des problèmes liés aux journaux](#troubleshooting-logs).

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.

**Topics**
+ [Erreur : le fichier de configuration ne contient pas CaPath le CertPath ou KeyPath. Le processus de démon Greengrass avec [pid = <pid>] a expiré.](#troubleshoot-config-file-version)
+ [Erreur : Impossible d'analyser/<greengrass-root>/config/config.json.](#troubleshoot-config-file-invalid)
+ [Erreur : Une erreur s'est produite lors de la génération de la configuration TLS : ErrUnknownURIScheme](#troubleshooting-unknown-uri-scheme)
+ [Erreur : échec de démarrage de Runtime : impossible de démarrer les composants Worker : le test de conteneur a expiré.](#troubleshoot-post-start-health-check)
+ [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 <address>tcp : getsockopt : connexion refusée, réponse : {}.](#troubleshoot-cloudwatch-logs)
+ [<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/:aws:lambda : ::function : :/lambda/arn: aucun fichier ou répertoire de ce <region>type.](#troubleshoot-lambda-executable-handler)
+ [Le logiciel AWS IoT Greengrass principal ne démarre pas une fois que vous êtes passé de l'exécution sans conteneurisation à l'exécution dans un conteneur Greengrass.](#troubleshoot-no-container)
+ [Erreur : la taille du dossier spool doit être d'au moins 262 144 octets.](#troubleshoot-spool-size)
+ [Erreur : [ERREUR] - Erreur de messagerie cloud : une erreur s'est produite lors de la tentative de publication d'un message. {"errorString": "operation timed out"}](#troubleshoot-mqtt-operation-timed-out)
+ [Erreur : container\_linux.go:344 : le démarrage du processus du conteneur a provoqué « process\_linux.go:424 : l'initialisation du conteneur a provoqué \\ » rootfs\_linux.go:64 : montage de \\ \\ \\ »/.sock \\ \\ \\ » sur rootfs \\ \\ \\ \\ »greengrass/ggc/\\ \\ \\ » à \\ \\ \\ » socket/greengrass\_ipc greengrass/ggc /greengrass\_ipc.sock \\ \\ \\ » \\ "stat//.sock : autorisation refusée \\ \\ \\" <version>rootfs/merged\\ "». greengrass/ggc socket/greengrass\_ipc](#troubleshoot-umask-permission)
+ [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.](#troubleshoot-system-components)
+ [Le shadow de l’appareil n'est pas synchronisé avec le cloud.](#troubleshoot-shadow-sync)
+ [ERREUR : impossible d'accepter la connexion TCP. accept tcp [::]:8000: accept4: trop de fichiers ouverts.](#troubleshoot-file-descriptor-limit)
+ [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\\\\\\"\\"".](#troubleshoot-execute-permissions)
+ [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.](#troubleshoot-mqttcertificate-warning)
+ [<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>.amazonaws. com/core<distribution-version>/<architecture>/greengrass-core- .tar.gz.](#troubleshoot-ota-region-access)
+ [Le AWS IoT Greengrass cœur est configuré pour utiliser un [proxy réseau](gg-core.md#alpn-network-proxy) et votre fonction Lambda ne peut pas établir de connexions sortantes.](#troubleshoot-lambda-proxy-network-connections)
+ [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.](#config-client-id)
+ [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 \\\\\\"](#troubleshoot-mount-proc-lambda-container)
+ [[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 »}](#troubleshoot-usr-access-root)
+ [[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 : statut de sortie 1"}](#troubleshoot-usr-access-root-canary)
+ [Erreur : [ERROR] -erreur d'exécution : impossible de démarrer le conteneur Lambda. <ggc-version><ggc-version><ggc-version>{"ErrorString » : « échec de l'initialisation des montages du conteneur : échec de la création de la superposition pour le conteneur : échec du montage dans/greengrass/ggc/packages///<ggc-version>: rootfs/merged échec du montage avec args source= \\" no\_source \\ » dest= \\ »//packages//\\ » <ggc-version>fstype= \\ "overlay \\ » flags= \\ "0 \\ » data= \\ "lowerdir=/ greengrass/ggc /packages/ rootfs/merged /dns:/, upperdir=/ /packages//, workdir=/ /packages//\\ » : trop de niveaux de liens symboliques "} greengrass/ggc greengrass/ggc rootfs/upper greengrass/ggc rootfs/work](#troubleshoot-symbolic-links)
+ [Error: [DEBUG]-Failed to get routes. Discarding message.](#troubleshoot-failed-to-get-routes)
+ [Error: [Errno 24] Too many open <lambda-function>,[Errno 24] Too many open files](#troubleshoot-too-many-open-files)
+ [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](#troubleshoot-install-path-too-long)
+ [[INFO] (Photocopieur) aws.greengrass. StreamManager: stdout. Causé par : com.fasterxml.jackson.databind. JsonMappingException: l'instant dépasse l'instant minimum ou maximum](#troubleshoot-stream-manager-instant-exceeds-maximun-minimum)
+ [GPG error: https://dnw9lb6lzp2d8.cloudfront.net stable InRelease: The following signatures were invalid: EXPKEYSIG 68D644ABD2327D47 AWS Greengrass Master Key](#troubleshoot-apt-repository-invalid-signature)

 

### Erreur : le fichier de configuration ne contient pas CaPath le CertPath ou KeyPath. Le processus de démon Greengrass avec [pid = <pid>] a expiré.
<a name="troubleshoot-config-file-version"></a>

**Solution :** cette erreur peut s'afficher `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 :
+ Effectuez une mise à niveau vers la version 1.7 ou ultérieure. Nous vous recommandons de toujours utiliser la dernière version du logiciel AWS IoT Greengrass Core. Pour obtenir des informations sur le téléchargement, consultez [Logiciel AWS IoT Greengrass Core](what-is-gg.md#gg-core-download-tab).
+ Utilisez le `config.json` format adapté à la version AWS IoT Greengrass de votre logiciel Core. Pour de plus amples informations, veuillez consulter [AWS IoT Greengrass fichier de configuration de base](gg-core.md#config-json).
**Note**  
<a name="find-ggc-version-intro"></a>Pour savoir quelle version du logiciel AWS IoT Greengrass Core est installée sur le périphérique principal, exécutez les commandes suivantes sur le terminal de votre appareil.  

  ```
  cd /{{greengrass-root}}/ggc/core/
  sudo ./greengrassd --version
  ```

 

### Erreur : Impossible d'analyser/<greengrass-root>/config/config.json.
<a name="troubleshoot-config-file-invalid"></a>

**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](gg-core.md#config-json) 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 : ErrUnknownURIScheme
<a name="troubleshooting-unknown-uri-scheme"></a>

**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](gg-core.md#config-json-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é.
<a name="troubleshoot-post-start-health-check"></a>

**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](gg-core.md#config-json). 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
  },
  ...
```

 

### 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 <address>tcp : getsockopt : connexion refusée, réponse : {}.
<a name="troubleshoot-cloudwatch-logs"></a>

**Solution :** vous pouvez voir cette erreur lorsque le logiciel AWS IoT Greengrass Core ne démarre pas. Cela peut se produire si vous utilisez AWS IoT Greengrass un Raspberry Pi et que la configuration de la mémoire requise n'est pas terminée. Pour plus d'informations, consultez [cette étape](setup-filter.rpi.md#stretch-step).

 

### <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/:aws:lambda : ::function : :/lambda/arn: aucun fichier ou répertoire de ce <region>type.
<a name="troubleshoot-lambda-executable-handler"></a>

**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](lambda-functions.md#lambda-executables) le noyau, vérifiez les `Handler` propriétés de la fonction dans le `group.json` fichier (situé 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](https://docs.aws.amazon.com/cli/latest/reference/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](https://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html).

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 principal ne démarre pas une fois que vous êtes passé de l'exécution sans conteneurisation à l'exécution dans un conteneur Greengrass.
<a name="troubleshoot-no-container"></a>

**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.
<a name="troubleshoot-spool-size"></a>

**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](gg-core.md#configure-local-storage-cache). 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"}
<a name="troubleshoot-mqtt-operation-timed-out"></a>

**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 utilisez la AWS IoT Greengrass version v1.10.2 ou une version ultérieure, essayez d'augmenter la `mqttOperationTimeout` valeur dans le [fichier config.json.](gg-core.md#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 : le démarrage du processus du conteneur a provoqué « process\_linux.go:424 : l'initialisation du conteneur a provoqué \\ » rootfs\_linux.go:64 : montage de \\ \\ \\ »/.sock \\ \\ \\ » sur rootfs \\ \\ \\ \\ »greengrass/ggc/\\ \\ \\ » à \\ \\ \\ » socket/greengrass\_ipc greengrass/ggc /greengrass\_ipc.sock \\ \\ \\ » \\ "stat//.sock : autorisation refusée \\ \\ \\" <version>rootfs/merged\\ "». greengrass/ggc socket/greengrass\_ipc
<a name="troubleshoot-umask-permission"></a>

**Solution :** cette erreur peut s'afficher `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.
<a name="troubleshoot-system-components"></a>

**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 de plus amples informations, veuillez consulter [Résolution des problèmes liés aux journaux](#troubleshooting-logs).

 

### Le shadow de l’appareil n'est pas synchronisé avec le cloud.
<a name="troubleshoot-shadow-sync"></a>

**Solution :** assurez-vous qu'il AWS IoT Greengrass dispose d'autorisations `iot:UpdateThingShadow` et d'`iot:GetThingShadow`actions pour le rôle de [service Greengrass](service-role.md). Si le rôle de service utilise la stratégie gérée `AWSGreengrassResourceAccessRolePolicy`, ces autorisations sont incluses par défaut.

Consultez [Dépannage des problèmes de temporisation de la synchronisation shadow](#troubleshooting-shadow-sync).

 

### ERREUR : impossible d'accepter la connexion TCP. accept tcp [::]:8000: accept4: trop de fichiers ouverts.
<a name="troubleshoot-file-descriptor-limit"></a>

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

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

```
ulimit -n 2048
```

**Note**  
Dans cet exemple, la limite est augmentée à 2 048. Choisissez une valeur adaptée à votre cas d'utilisation.

 

### 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\\\\\\"\\"".
<a name="troubleshoot-execute-permissions"></a>

**Solution :** effectuez l'installation AWS IoT Greengrass directement dans le répertoire racine ou assurez-vous que le répertoire dans lequel le logiciel AWS IoT Greengrass Core est installé et ses répertoires parents disposent d'`execute`autorisations 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.
<a name="troubleshoot-mqttcertificate-warning"></a>

**Solution :** AWS IoT Greengrass utilise un gestionnaire commun pour valider les propriétés de tous les principes 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 de plus amples informations, veuillez consulter [AWS IoT Greengrass principes de sécurité fondamentaux](gg-sec.md#gg-principals).

 

### <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>.amazonaws. com/core<distribution-version>/<architecture>/greengrass-core- .tar.gz.
<a name="troubleshoot-ota-region-access"></a>

**Solution :** vous pouvez voir cette erreur lorsqu'une mise à jour OTA échoue. Dans la politique de rôle du signataire, ajoutez la cible Région AWS en tant que`Resource`. Ce rôle de signataire est utilisé pour présigner l'URL S3 pour la mise à jour AWS IoT Greengrass logicielle. Pour plus d'informations, consultez [Rôle de signataire d'URL S3](core-ota-update.md#s3-url-signer-role).

 

### Le AWS IoT Greengrass cœur est configuré pour utiliser un [proxy réseau](gg-core.md#alpn-network-proxy) et votre fonction Lambda ne peut pas établir de connexions sortantes.
<a name="troubleshoot-lambda-proxy-network-connections"></a>

**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 délai 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 Greengrass transmet la configuration du proxy aux fonctions Lambda définies par l'utilisateur via `http_proxy` les variables d'`https_proxy`environnement, `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.

**Note**  
Les bibliothèques courantes utilisées pour établir des connexions (par exemple, boto3 ou cURL et les packages `requests` Python) se servent de ces variables d'environnement par défaut.

 

### 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.
<a name="config-client-id"></a>

**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.

**Pour remplacer l'ID client par défaut pour le périphérique principal**

1. Exécutez la commande suivante pour arrêter le daemon Greengrass :

   ```
   cd /{{greengrass-root}}/ggc/core/
   sudo ./greengrassd stop
   ```

1. Ouvrez `{{greengrass-root}}/config/config.json` pour le modifier en tant qu'utilisateur su.

1. Dans l'objet `coreThing`, ajoutez la propriété `coreClientId` et définissez la valeur sur votre ID client personnalisé. La valeur doit comprendre entre 1 et 128 caractères. Il doit être unique dans le courant Région AWS pour le Compte AWS.

   ```
   "coreClientId": "MyCustomClientId"
   ```

1. Lancez le démon.

   ```
   cd /{{greengrass-root}}/ggc/core/
   sudo ./greengrassd start
   ```

 

### 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 \\\\\\"
<a name="troubleshoot-mount-proc-lambda-container"></a>

**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 :
+ Activez l'option `CONFIG_DEVPTS_MULTIPLE_INSTANCES` dans le noyau Linux.
+ Définissez les options de montage `/proc` sur l'hôte sur `rw,relatim` uniquement.
+ Mettez à niveau le noyau Linux vers la version 4.9 ou ultérieure.

**Note**  
Ce problème n'est pas lié au montage `/proc` pour l'accès aux ressources locales.

 

### [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 »}
<a name="troubleshoot-usr-access-root"></a>

**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 :
+ Spécifier `/usr` comme **chemin source** et **chemin de destination**
+ Ajouter automatiquement les autorisations de groupe de système d'exploitation du groupe Linux qui possède la ressource
+ Affiliez-vous à la fonction Lambda et autorisez l'accès en lecture seule.

 

### [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 : statut de sortie 1"}
<a name="troubleshoot-usr-access-root-canary"></a>

**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 :
+ Spécifier `/usr` comme **chemin source** et **chemin de destination**
+ Ajouter automatiquement les autorisations de groupe de système d'exploitation du groupe Linux qui possède la ressource
+ Affiliez-vous à la fonction Lambda et autorisez l'accès en lecture seule.

 

### Erreur : [ERROR] -erreur d'exécution : impossible de démarrer le conteneur Lambda. <ggc-version><ggc-version><ggc-version>{"ErrorString » : « échec de l'initialisation des montages du conteneur : échec de la création de la superposition pour le conteneur : échec du montage dans/greengrass/ggc/packages///<ggc-version>: rootfs/merged échec du montage avec args source= \\" no\_source \\ » dest= \\ »//packages//\\ » <ggc-version>fstype= \\ "overlay \\ » flags= \\ "0 \\ » data= \\ "lowerdir=/ greengrass/ggc /packages/ rootfs/merged /dns:/, upperdir=/ /packages//, workdir=/ /packages//\\ » : trop de niveaux de liens symboliques "} greengrass/ggc greengrass/ggc rootfs/upper greengrass/ggc rootfs/work
<a name="troubleshoot-symbolic-links"></a>

**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 :

1. Mettez à niveau le logiciel AWS IoT Greengrass Core vers la version v1.9.3 ou ultérieure. Cela devrait résoudre automatiquement ce problème.

1. Si cette erreur persiste après la mise à niveau du logiciel AWS IoT Greengrass Core, définissez la `system.useOverlayWithTmpfs` propriété sur `true` dans le [fichier config.json.](gg-core.md#config-json)   
**Example Exemple**  

   ```
   {
     "system": {
       "useOverlayWithTmpfs": true
     },
     "coreThing": {
       "caPath": "root-ca.pem",
       "certPath": "cloud.pem.crt",
       "keyPath": "cloud.pem.key",
       ...
     },
     ...
   }
   ```

**Note**  
La version AWS IoT Greengrass de votre logiciel Core s'affiche dans le message d'erreur. Pour rechercher la version de votre noyau Linux, exécutez `uname -r`.

 

### Error: [DEBUG]-Failed to get routes. Discarding message.
<a name="troubleshoot-failed-to-get-routes"></a>

**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
<a name="troubleshoot-too-many-open-files"></a>

**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 de plus amples informations, veuillez consulter [StreamManagerClient À utiliser pour travailler avec des flux](work-with-streams.md). 

 

### 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
<a name="troubleshoot-install-path-too-long"></a>

**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](gg-core.md#write-directory), 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
<a name="troubleshoot-stream-manager-instant-exceeds-maximun-minimum"></a>

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
<a name="troubleshoot-apt-repository-invalid-signature"></a>

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](install-ggc.md#ggc-package-manager), 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éussie`apt 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
<a name="gg-troubleshooting-deploymentissues"></a>

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

**Topics**
+ [Votre déploiement actuel ne fonctionne pas et vous souhaitez revenir à un déploiement opérationnel précédent.](#troubleshoot-revert-deployment)
+ [L'erreur 403 Interdit s'affiche dans les journaux lors du déploiement.](#troubleshoot-forbidden-deployment)
+ [Une ConcurrentDeployment erreur se produit lorsque vous exécutez la commande create-deployment pour la première fois.](#troubleshoot-concurrent-deployment)
+ [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.](#troubleshoot-assume-service-role)
+ [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](#troubleshoot-x509-certificate-expired)
+ [Le déploiement n'est pas terminé.](#troubleshoot-stuck-deployment)
+ [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](#java-8-runtime-requirement)
+ [Le déploiement n'est pas terminé et runtime.log contient plusieurs entrées « attendre 1 s que le conteneur s'arrête ».](#troubleshoot-wait-container-stop)
+ [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"} ».](#troubleshoot-failed-to-report-deployment-status)
+ [<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 :.](#troubleshoot-access-permissions-deployment)
+ [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.](#troubleshoot-root-permissions-lambda)
+ [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.](#troubleshoot-could-not-find-uid)
+ [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"}](#troubleshoot-failed-to-initialize-container-mounts)
+ [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 \\ "».](#troubleshoot-wait-child-processes)
+ [<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 pendant l'attente de la connexion (Client.Timeout dépassé pendant l'attente des en-têtes)](#troubleshoot-dnssec-validation-failed)

 

### Votre déploiement actuel ne fonctionne pas et vous souhaitez revenir à un déploiement opérationnel précédent.
<a name="troubleshoot-revert-deployment"></a>

**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.

**Pour redéployer un déploiement (console)**

1. Sur la page de configuration du groupe, choisissez l'onglet **Déploiements**. Cette page affiche l'historique de déploiement du groupe, y compris la date et l'heure, la version du groupe et l'état de chaque tentative de déploiement.

1. Recherchez la ligne qui contient le déploiement que vous souhaitez redéployer. Sélectionnez le déploiement que vous souhaitez redéployer, puis choisissez **Redéployer**.  
![Page de déploiements présentant l' Re-Deploy action à effectuer pour un déploiement.](http://docs.aws.amazon.com/fr_fr/greengrass/v1/developerguide/images/console-group-redeployment.png)

**Pour redéployer un déploiement (interface de ligne de commande)**

1. [ListDeployments](https://docs.aws.amazon.com/greengrass/v1/apireference/listdeployments-get.html)Utilisez-le pour trouver l'ID du déploiement que vous souhaitez redéployer. Par exemple :

   ```
   aws greengrass list-deployments --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7
   ```

   La commande renvoie la liste des déploiements pour le groupe.

   ```
   {
       "Deployments": [
           {
               "DeploymentId": "8d179428-f617-4a77-8a0c-3d61fb8446a6",
               "DeploymentType": "NewDeployment",
               "GroupArn": "arn:aws:greengrass:us-west-2:123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/8dd1d899-4ac9-4f5d-afe4-22de086efc62",
               "CreatedAt": "2019-07-01T20:56:49.641Z"
           },
           {
               "DeploymentId": "f8e4c455-8ac4-453a-8252-512dc3e9c596",
               "DeploymentType": "NewDeployment",
               "GroupArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/4ad66e5d-3808-446b-940a-b1a788898382",
               "CreatedAt": "2019-07-01T20:41:47.048Z"
           },
           {
               "DeploymentId": "e4aca044-bbd8-41b4-b697-930ca7c40f3e",
               "DeploymentType": "NewDeployment",
               "GroupArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/1f3870b6-850e-4c97-8018-c872e17b235b",
               "CreatedAt": "2019-06-18T15:16:02.965Z"
           }
       ]
   }
   ```
**Note**  
Ces AWS CLI commandes utilisent des exemples de valeurs pour le groupe et l'ID de déploiement. Lorsque vous exécutez les commandes, veillez à remplacer les exemples de valeurs.

1. [CreateDeployment](https://docs.aws.amazon.com/greengrass/v1/apireference/createdeployment-post.html)À utiliser pour redéployer le déploiement cible. Définissez le type de déploiement sur `Redeployment`. Par exemple :

   ```
   aws greengrass create-deployment --deployment-type Redeployment \ 
     --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7 \
     --deployment-id f8e4c455-8ac4-453a-8252-512dc3e9c596
   ```

   La commande renvoie l'ARN et l'ID du nouveau déploiement.

   ```
   {
       "DeploymentId": "f9ed02b7-c28e-4df6-83b1-e9553ddd0fc2",
       "DeploymentArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/deployments/f9ed02b7-c28e-4df6-83b1-e9553ddd0fc2"
   }
   ```

1. [GetDeploymentStatus](https://docs.aws.amazon.com/greengrass/v1/apireference/getdeploymentstatus-get.html)Utilisez-le pour obtenir l'état du déploiement.

 

### L'erreur 403 Interdit s'affiche dans les journaux lors du déploiement.
<a name="troubleshoot-forbidden-deployment"></a>

**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.
<a name="troubleshoot-concurrent-deployment"></a>

**Solution :** un déploiement est peut-être en cours. Vous pouvez exécuter la commande [get-deployment-status](https://docs.aws.amazon.com/greengrass/v1/apireference/getdeploymentstatus-get.html) 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.
<a name="troubleshoot-assume-service-role"></a>

**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)](service-role.md#manage-service-role-cli) ou [Gestion du rôle de service Greengrass (console)](service-role.md#manage-service-role-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
<a name="troubleshoot-x509-certificate-expired"></a>

**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. Le protocole TLS et les X.509 certificats constituent une base sûre pour la création de systèmes IoT, mais ils nécessitent des heures précises sur les serveurs et les clients. Les appareils IoT doivent avoir l'heure exacte (dans les 15 minutes) avant de tenter de se connecter à un autre service TLS utilisant des certificats de serveur AWS IoT Greengrass ou de le faire. Pour plus d'informations, consultez la section [Utilisation de l'heure de l'appareil pour valider les certificats de AWS IoT serveur](https://aws.amazon.com/blogs/iot/using-device-time-to-validate-aws-iot-server-certificates/) sur *l'Internet des objets sur le blog AWS officiel*.

 

### Le déploiement n'est pas terminé.
<a name="troubleshoot-stuck-deployment"></a>

**Solution :** effectuez les opérations suivantes :
+ Assurez-vous que le AWS IoT Greengrass daemon est en cours d'exécution sur votre appareil principal. Dans le terminal de votre appareil principal, exécutez les commandes suivantes pour vérifier si le démon est en cours d'exécution et démarrez-le, si nécessaire.

  1. Pour vérifier si le démon est en cours d'exécution :

     ```
     ps aux | grep -E 'greengrass.*daemon'
     ```

     Si la sortie contient une entrée `root` pour `/greengrass/ggc/packages/1.11.6/bin/daemon`, le démon est en cours d'exécution.

     La version indiquée dans le chemin dépend de la version du logiciel AWS IoT Greengrass Core installée sur votre appareil principal.

  1. Pour démarrer le daemon, procédez comme suit :

     ```
     cd /greengrass/ggc/core/
     sudo ./greengrassd start
     ```
+ Assurez-vous que votre appareil principal est connecté et que les points de terminaison de connexion à l'appareil principal sont configurés correctement.

 

### 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
<a name="java-8-runtime-requirement"></a>

**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](stream-manager.md#stream-manager-requirements) 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 de plus amples informations, veuillez consulter [Configurer les paramètres du gestionnaire de flux (console)](configure-stream-manager.md#configure-stream-manager-console).

 

### Le déploiement n'est pas terminé et runtime.log contient plusieurs entrées « attendre 1 s que le conteneur s'arrête ».
<a name="troubleshoot-wait-container-stop"></a>

**Solution :** Exécutez les commandes suivantes dans le terminal de votre appareil principal pour redémarrer le AWS IoT Greengrass daemon.

```
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"} ».
<a name="troubleshoot-failed-to-report-deployment-status"></a>

**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](gg-core.md#config-json).

**Note**  
{{greengrass-root}}représente le chemin d'installation du logiciel AWS IoT Greengrass Core sur votre appareil. Généralement, il s'agit du répertoire `/greengrass`.

 

### <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 :.
<a name="troubleshoot-access-permissions-deployment"></a>

**Solution :** Assurez-vous que le groupe de propriétaires du {{<path>}} répertoire 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.
<a name="troubleshoot-root-permissions-lambda"></a>

**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 en `yes` ou modifiez la fonction Lambda `greengrass_root/config/config.json` pour qu'elle s'exécute comme une autre. user/group Pour de plus amples informations, veuillez consulter [Exécution d'une fonction Lambda en tant que root](lambda-group-config.md#lambda-running-as-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.
<a name="troubleshoot-could-not-find-uid"></a>

**Solution :** Si l'[identité d'accès par défaut](lambda-group-config.md#lambda-access-identity-groupsettings) du AWS IoT Greengrass groupe utilise les comptes système standard, l'`ggc_user`utilisateur 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](setup-filter.rpi.md#add-ggc-user-ggc-group). 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"}
<a name="troubleshoot-failed-to-initialize-container-mounts"></a>

**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](access-local-resources.md) au groupe, puis déployez le groupe. La ressource doit :
+ Spécifier `/usr` comme **chemin source** et **chemin de destination**
+ Ajouter automatiquement les autorisations de groupe de système d'exploitation du groupe Linux qui possède la ressource
+ Affiliez-vous à la fonction Lambda et autorisez l'accès en lecture seule.

 

### 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 \\ "».
<a name="troubleshoot-wait-child-processes"></a>

**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 pendant l'attente de la connexion (Client.Timeout dépassé pendant l'attente des en-têtes)
<a name="troubleshoot-dnssec-validation-failed"></a>

**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 pour atteindre le AWS IoT Greengrass point de terminaison ne parviennent pas à trouver l'hôte, vos déploiements restent donc inchangés`In Progress`.

Vous pouvez utiliser les commandes et la sortie suivantes pour tester ce problème. Remplacez l'{{region}}espace réservé 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](https://github.com/systemd/systemd/issues/9867) pour `systemd`.

1. Ajoutez `DNSSEC=false` à `/etc/systemd/resolved.conf`.

1. Redémarrez `systemd-resolved`.

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
<a name="gg-troubleshooting-groupcreateissues"></a>

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.

**Topics**
+ [Erreur : votre configuration « IsolationMode » pour le groupe n'est pas valide.](#troubleshoot-invalid-isolation-mode-group)
+ [Erreur : votre configuration « IsolationMode » pour la fonction avec arn <function-arn>n'est pas valide.](#troubleshoot-isolation-mode-lambda)
+ [Erreur : MemorySize la configuration de la fonction avec arn <function-arn>n'est pas autorisée dans IsolationMode =NoContainer.](#troubleshoot-lambda-memorysize-not-supported)
+ [Erreur : la configuration Access Sysfs pour la fonction avec arn <function-arn>n'est pas autorisée dans IsolationMode =. NoContainer](#troubleshoot-sysfs-access-not-supported)
+ [Erreur : MemorySize la configuration de la fonction avec arn <function-arn>est requise dans IsolationMode =GreengrassContainer.](#troubleshoot-lambda-memorysize-required)
+ [Erreur : <function-arn>La fonction fait référence à une ressource <resource-type>dont le type n'est pas autorisé dans IsolationMode =NoContainer.](#troubleshoot-resource-access-not-supported)
+ [Erreur : la configuration d'Execution pour la fonction ayant l'arn <arn-fonction> n'est pas autorisée.](#troubleshoot-execution-parameters-not-supported)

 

### Erreur : votre configuration « IsolationMode » pour le groupe n'est pas valide.
<a name="troubleshoot-invalid-isolation-mode-group"></a>

**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.
<a name="troubleshoot-isolation-mode-lambda"></a>

**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.
<a name="troubleshoot-lambda-memorysize-not-supported"></a>

**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
<a name="troubleshoot-sysfs-access-not-supported"></a>

**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.
<a name="troubleshoot-lambda-memorysize-required"></a>

**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.
<a name="troubleshoot-resource-access-not-supported"></a>

**Solution :** Vous ne pouvez pas accéder aux types de `S3_Object.Generic_Archive` ressources `Local.Device` `Local.Volume` `ML_Model.SageMaker.Job``ML_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 AWS IoT Greengrass conteneur. 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.
<a name="troubleshoot-execution-parameters-not-supported"></a>

**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
<a name="gg-troubleshooting-discovery-issues"></a>

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

**Topics**
+ [Erreur : l'appareil appartient à un trop grand nombre de groupes, les appareils ne peuvent pas être dans plus de 10 groupes](#troubleshoot-device-in-too-many-groups)

 

### Erreur : l'appareil appartient à un trop grand nombre de groupes, les appareils ne peuvent pas être dans plus de 10 groupes
<a name="troubleshoot-device-in-too-many-groups"></a>

**Solution :** il s'agit d'une limitation connue. Un [appareil client](what-is-gg.md#greengrass-devices) peut appartenir à un maximum de 10 groupes.

 

## Problèmes liés aux ressources de machine learning
<a name="ml-resources-troubleshooting"></a>

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

**Topics**
+ [InvalidMLModelOwner - GroupOwnerSetting est fourni dans la ressource du modèle ML, mais GroupOwner n' GroupPermission est pas présent](#nocontainer-lambda-invalid-ml-model-owner)
+ [NoContainer La fonction ne peut pas configurer les autorisations lors de l'attachement de ressources Machine Learning. <function-arn>fait référence à la ressource Machine Learnin <resource-id>avec l'autorisation < ro/rw > dans la politique d'accès aux ressources.](#nocontainer-lambda-invalid-resource-access-policy)
+ [<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.](#nocontainer-lambda-missing-access-permission)
+ [<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 \\ ».](#container-lambda-invalid-rw-permissions)
+ [NoContainer La fonction <function-arn>fait référence aux ressources du chemin de destination imbriqué.](#nocontainer-lambda-nested-destination-path)
+ [La fonction Lambda <function-arn> accède à la ressource <resource-id> en partageant le même identifiant de propriétaire de groupe](#lambda-runas-and-resource-owner)

 

### InvalidMLModelOwner - GroupOwnerSetting est fourni dans la ressource du modèle ML, mais GroupOwner n' GroupPermission est pas présent
<a name="nocontainer-lambda-invalid-ml-model-owner"></a>

**Solution :** vous recevez cette erreur si une ressource d'apprentissage automatique contient l'[ResourceDownloadOwnerSetting](https://docs.aws.amazon.com/greengrass/v1/apireference/definitions-resourcedownloadownersetting.html)objet 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 à la ressource Machine Learnin <resource-id>avec l'autorisation < ro/rw > dans la politique d'accès aux ressources.
<a name="nocontainer-lambda-invalid-resource-access-policy"></a>

**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. Non-containerized les fonctions doivent hériter des autorisations du propriétaire de la ressource définies sur la ressource d'apprentissage automatique. Pour résoudre ce problème, choisissez d'[hériter des autorisations du propriétaire des ressources](access-ml-resources.md#non-container-config-console) (console) ou de [supprimer les autorisations de la politique d'accès aux ressources (API) de la fonction Lambda](access-ml-resources.md#non-container-config-api).

 

### <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.
<a name="nocontainer-lambda-missing-access-permission"></a>

**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 [ResourceAccessPolicy](https://docs.aws.amazon.com/greengrass/v1/apireference/definitions-resourceaccesspolicy.html)propriété de la fonction Lambda ou dans la [OwnerSetting](https://docs.aws.amazon.com/greengrass/v1/apireference/definitions-ownersetting.html)proprié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 \\ ».
<a name="container-lambda-invalid-rw-permissions"></a>

**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é.
<a name="nocontainer-lambda-nested-destination-path"></a>

**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
<a name="lambda-runas-and-resource-owner"></a>

**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](access-ml-resources.md#ml-resource-owner) d'apprentissage automatique, mais que](lambda-group-config.md#lambda-access-identity) 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.

## AWS IoT Greengrass principaux problèmes liés à Docker
<a name="gg-troubleshooting-dockerissues"></a>

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.

**Topics**
+ [Erreur : options inconnues : -no-include-email.](#docker-troubleshooting-cli-version)
+ [Avertissement : IPv4 est désactivé. La mise en réseau ne fonctionnera pas.](#docker-troubleshooting-ipv4-disabled)
+ [Erreur : Un pare-feu bloque le partage de fichiers entre les fenêtres et les conteneurs.](#docker-troubleshooting-firewall)
+ [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](#docker-troubleshooting-ecr-perms)
+ [Erreur : Impossible de créer un conteneur pour le service greengrass : conflit. Le nom de conteneur « /aws-iot-greengrass » est déjà en cours d'utilisation.](#troubleshoot-docker-name-conflict)
+ [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.](#troubleshoot-docker-container-lambda)

 

### Erreur : options inconnues : -no-include-email.
<a name="docker-troubleshooting-cli-version"></a>

**Solution :** cette erreur peut se produire lorsque vous exécutez la commande `aws ecr get-login`. Assurez-vous que la dernière AWS CLI version est 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](https://docs.aws.amazon.com/cli/latest/userguide/awscli-install-windows.html) dans le *Guide de AWS Command Line Interface l'utilisateur*.

 

### Avertissement : IPv4 est désactivé. La mise en réseau ne fonctionnera pas.
<a name="docker-troubleshooting-ipv4-disabled"></a>

**Solution :** vous pouvez recevoir cet avertissement ou un message similaire lors de l'exécution AWS IoT Greengrass sur un ordinateur Linux. Activez le transfert réseau IPv4 comme décrit dans cette [étape](run-gg-in-docker-container.md#docker-linux-enable-ipv4). AWS IoT Greengrass le déploiement dans le cloud et les communications MQTT ne fonctionnent pas lorsque le transfert 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](https://docs.docker.com/engine/reference/commandline/run/#configure-namespaced-kernel-parameters-sysctls-at-runtime) dans la documentation Docker.

 

### Erreur : Un pare-feu bloque le partage de fichiers entre les fenêtres et les conteneurs.
<a name="docker-troubleshooting-firewall"></a>

**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
<a name="docker-troubleshooting-ecr-perms"></a>

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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policy-examples.html) et [l'accès à un référentiel Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/security_iam_id-based-policy-examples.html) dans le guide de l'utilisateur *Amazon ECR.*

 

### Erreur : Impossible de créer un conteneur pour le service greengrass : conflit. Le nom de conteneur « /aws-iot-greengrass » est déjà en cours d'utilisation.
<a name="troubleshoot-docker-name-conflict"></a>

**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.
<a name="troubleshoot-docker-container-lambda"></a>

**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](lambda-group-config.md#change-containerization-lambda) 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 de plus amples informations, veuillez consulter [Exécution AWS IoT Greengrass dans un conteneur Docker](run-gg-in-docker-container.md).

## Résolution des problèmes liés aux journaux
<a name="troubleshooting-logs"></a>

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 de plus amples informations, veuillez consulter [Configurer la journalisation pour AWS IoT Greengrass](greengrass-logs-overview.md#config-logs).

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

`{{greengrass-root}}/ggc/var/log/crash.log`  
Affiche les messages générés lorsqu'un AWS IoT Greengrass noyau tombe en panne.

`{{greengrass-root}}/ggc/var/log/system/runtime.log`  
Affiche les messages sur le composant qui est en échec.

`{{greengrass-root}}/ggc/var/log/system/`  
Contient tous les journaux des composants du AWS IoT Greengrass système, tels que le gestionnaire de certificats et le gestionnaire de connexions. En utilisant les messages contenus dans `ggc/var/log/system/` et`ggc/var/log/system/runtime.log`, vous devriez être en mesure de savoir quelle erreur s'est produite dans les composants AWS IoT Greengrass du système.

`{{greengrass-root}}/ggc/var/log/system/localwatch/`  
Contient les journaux du AWS IoT Greengrass composant qui gère le téléchargement des journaux Greengrass vers Logs CloudWatch . Si vous ne pouvez pas consulter les connexions Greengrass CloudWatch, vous pouvez utiliser ces journaux pour résoudre les problèmes.

`{{greengrass-root}}/ggc/var/log/user/`  
Contient tous les journaux des fonctions Lambda définies par l'utilisateur. Consultez ce dossier pour trouver les messages d'erreur provenant de vos fonctions Lambda locales.

**Note**  
Par défaut, {{greengrass-root}} est le répertoire `/greengrass`. Si un [répertoire en écriture](gg-core.md#write-directory) est configuré, les journaux se trouvent dans ce répertoire.

Si les journaux sont configurés pour être stockés dans le cloud, utilisez CloudWatch Logs pour afficher les messages des journaux. `crash.log`se 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 AWS IoT Greengrass journalisation, consultez[Surveillance à l'aide de AWS IoT Greengrass journaux](greengrass-logs-overview.md).

**Note**  
Les journaux du logiciel AWS IoT Greengrass Core v1.0 sont stockés dans le `{{greengrass-root}}/var/log` répertoire.

## Résolution des problèmes de stockage
<a name="troubleshooting-storage"></a>

Lorsque le stockage de fichiers local est plein, il se peut que certains composants commencent à tomber en panne : 
+ Les mises à jour locales de Shadow ne se produisent pas.
+ Les nouveaux certificats de serveur MQTT AWS IoT Greengrass principaux ne peuvent pas être téléchargés localement.
+ Les déploiements échouent.

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 (voir[Résolution des problèmes liés aux journaux](#troubleshooting-logs)) et du nombre d'ombres stockées localement. 

## Messages de résolution des problèmes
<a name="troubleshooting-messages"></a>

Tous les messages envoyés localement 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, il AWS IoT Greengrass risque de ne pas démarrer correctement. Pour de plus amples informations, veuillez consulter [File d'attente de messages MQTT pour les cibles cloud](gg-core.md#mqtt-message-queue).

**Note**  
Lorsque vous utilisez la file d'attente en mémoire par défaut, nous vous recommandons de déployer des groupes ou de redémarrer l'appareil lorsque l'interruption de service est la moins importante.

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 de plus amples informations, veuillez consulter [Sessions persistantes MQTT avec AWS IoT Core](gg-core.md#mqtt-persistent-sessions).

## Dépannage des problèmes de temporisation de la synchronisation shadow
<a name="troubleshooting-shadow-sync"></a>

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](gg-core.md#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`.

**Note**  
Pour les versions 1.6 et antérieures du logiciel AWS IoT Greengrass Core, la valeur par défaut `shadowSyncTimeout` est de 1 seconde.

## Vérifiez AWS Re:post
<a name="troubleshooting-repost"></a>

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 AWS IoT Greengrass](#gg-troubleshooting) ou consulter le [AWS IoT Greengrass tag sur AWS Re:post](https://repost.aws/tags/TA4ckIed1sR4enZBey29rKTg/aws-io-t-greengrass) ou publier une nouvelle question. Les membres de l' AWS IoT Greengrass équipe surveillent activement AWS Re:post.