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 liés à IDT pour V2 AWS IoT Greengrass
IDT pour AWS IoT Greengrass V2 écrit les erreurs à différents emplacements en fonction du type d'erreur. IDT écrit les erreurs dans la console, les fichiers journaux et les rapports de test.
## Où rechercher les erreurs
Les erreurs de haut niveau s'affichent sur la console pendant l'exécution du test, et un résumé des tests ayant échoué s'affiche lorsque tous les tests sont terminés. `awsiotdevicetester_report.xml`contient un résumé de toutes les erreurs à l'origine de l'échec d'un test. IDT stocke les fichiers journaux de chaque test dans un répertoire avec un UUID pour l'exécution du test, affiché sur la console pendant l'exécution du test.
Le répertoire des journaux de test IDT est`{{}}/results/{{}}/logs/`. Ce répertoire contient les fichiers suivants affichés dans le tableau. Ce paramètre est utile pour le débogage.
| Fichier | Description |
| --- | --- |
| test\_manager.log | Les journaux écrits sur la console pendant l'exécution du test. Le résumé des résultats à la fin de ce fichier inclut une liste des tests qui ont échoué.
Les journaux des erreurs et des avertissements de ce fichier peuvent vous donner des informations sur les défaillances. |
| {{test-group-id}}/{{test-case-id}}/{{test-name}}.log | Journaux détaillés du test spécifique effectué dans un groupe de test. Pour les tests qui déploient des composants Greengrass, le fichier journal des scénarios de test est appelé. greengrass-test-run.log |
| {{test-group-id}}/{{test-case-id}}/greengrass.log | Journaux détaillés AWS IoT Greengrass du logiciel Core. IDT copie ce fichier depuis le périphérique testé lorsqu'il exécute des tests d'installation du logiciel AWS IoT Greengrass Core sur l'appareil. Pour plus d'informations sur les messages contenus dans ce fichier journal, consultez[Résolution des problèmes AWS IoT Greengrass V2](troubleshooting.md). |
| {{test-group-id}}/{{test-case-id}}/{{component-name}}.log | Journaux détaillés des composants Greengrass déployés lors des tests. IDT copie les fichiers journaux des composants depuis le périphérique testé lorsqu'il exécute des tests qui déploient des composants spécifiques. Le nom du fichier journal de chaque composant correspond au nom du composant déployé. Pour plus d'informations sur les messages contenus dans ce fichier journal, consultez[Résolution des problèmes AWS IoT Greengrass V2](troubleshooting.md). |
## Résolution des erreurs IDT pour la AWS IoT Greengrass V2
Avant d'exécuter IDT for AWS IoT Greengrass, installez les fichiers de configuration appropriés. Si vous recevez des erreurs d'analyse et de configuration, la première étape consiste à rechercher et à utiliser un modèle de configuration adapté à votre environnement.
Si le problème persiste, consultez les processus de débogage suivants.
**Topics**
+ [Erreurs de résolution d'alias](#alias-resolution-errors)
+ [Erreurs liées aux conflits](#conflict-error)
+ [Erreur indiquant l'impossibilité de démarrer le test](#could-not-start-test)
+ [L'image de qualification Docker existe des erreurs](#docker-qualification-image-exists)
+ [Impossible de lire les informations d'identification](#failed-to-read-credential-windows)
+ [Erreurs de guidage avec Greengrass PreInstalled](#guice-errors)
+ [Exception de signature non valide](#invalid-signature-exception-lambda)
+ [Erreurs de qualification liées à l'apprentissage automatique](#machine-learning-qualification-failure)
+ [Les déploiements d'Open Test Framework (OTF) ont échoué](#otf-deployment-failure)
+ [Erreurs d'analyse](#parse-error)
+ [Erreurs de type « Autorisation refusée »](#permission-denied-pwd-sudo)
+ [Erreur lors de la génération du rapport de qualification](#qualification-report-policy-error)
+ [Erreur liée à un paramètre obligatoire manquant](#required-param-missing)
+ [Exception de sécurité sur macOS](#security-exception-macos)
+ [Erreurs de connexion SSH](#ssh-connect-errors)
+ [Erreurs de qualification du gestionnaire de flux](#stream-manager-qualification-failure)
+ [Erreurs de délai d'attente](#test-timeout)
+ [Erreurs de vérification de version](#version-compatibility-check-failure)
### Erreurs de résolution d'alias
Lorsque vous exécutez des suites de tests personnalisées, l'erreur suivante peut s'afficher dans la console et dans le`test_manager.log`.
```
Couldn't resolve placeholders: couldn't do a json lookup: index out of range
```
Cette erreur peut se produire lorsque les alias configurés dans l'orchestrateur de test IDT ne sont pas résolus correctement ou si les valeurs résolues ne sont pas présentes dans les fichiers de configuration. Pour résoudre cette erreur, assurez-vous que votre `device.json` et `userdata.json ` contient les informations correctes requises pour votre suite de tests. Pour plus d'informations sur la configuration requise pour la AWS IoT Greengrass qualification, consultez[Configurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification](set-config.md).
### Erreurs liées aux conflits
L'erreur suivante peut s'afficher lorsque vous exécutez la suite de AWS IoT Greengrass qualification simultanément sur plusieurs appareils.
```
ConflictException: Component [com.example.IDTHelloWorld : 1.0.0] for account [{{account-id}}] already exists with state: [DEPLOYABLE] { RespMetadata: { StatusCode: 409, RequestID: “{{id}}” }, Message_: “Component [com.example.IDTHelloWorld : 1.0.0] for account [{{account-id}}] already exists with state: [DEPLOYABLE]” }
```
L'exécution simultanée de tests n'est pas encore prise en charge pour la suite de AWS IoT Greengrass qualification. Exécutez la suite de qualification de manière séquentielle pour chaque appareil.
### Erreur indiquant l'impossibilité de démarrer le test
Vous pouvez rencontrer des erreurs indiquant des échecs survenus lors de la tentative de démarrage du test. Il y a plusieurs causes possibles. Par conséquent, procédez de la façon suivante :
+ Assurez-vous que le nom du pool indiqué dans votre commande d'exécution existe bien. IDT référence le nom du pool directement à partir de votre `device.json` fichier.
+ Assurez-vous que les appareils du groupe ont des paramètres de configuration corrects.
### L'image de qualification Docker existe des erreurs
Les tests de qualification du gestionnaire d'applications Docker utilisent l'image du `amazon/amazon-ec2-metadata-mock` conteneur dans Amazon ECR pour qualifier l'appareil testé.
Le message d'erreur suivant peut s'afficher si l'image est déjà présente dans un conteneur Docker sur l'appareil testé.
```
The Docker image amazon/amazon-ec2-metadata-mock:{{version}} already exists on the device.
```
Si vous avez déjà téléchargé cette image et exécuté le `amazon/amazon-ec2-metadata-mock` conteneur sur votre appareil, assurez-vous de supprimer cette image de l'appareil testé avant d'exécuter les tests de qualification.
### Impossible de lire les informations d'identification
Lorsque vous testez des appareils Windows, vous pouvez rencontrer l'`Failed to read credential`erreur dans le `greengrass.log` fichier si l'utilisateur que vous utilisez pour vous connecter à l'appareil testé n'est pas configuré dans le gestionnaire d'informations d'identification de cet appareil.
Pour résoudre cette erreur, configurez l'utilisateur et le mot de passe de l'utilisateur IDT dans le gestionnaire d'informations d'identification de l'appareil testé.
Pour de plus amples informations, veuillez consulter [Configuration des informations d'identification utilisateur pour les appareils Windows](device-config-setup.md#configure-windows-user-for-idt).
### Erreurs de guidage avec Greengrass PreInstalled
Lors de PreInstalled l'exécution d'IDT avec Greengrass, si vous rencontrez une erreur `Guice` `ErrorInCustomProvider` ou vérifiez si le `userdata.json` fichier est défini dans le dossier d'`InstalledDirRootOnDevice`installation de Greengrass. IDT vérifie la présence du fichier ci-dessous`effectiveConfig.yaml`. `/config/effectiveConfig.yaml`
Pour de plus amples informations, veuillez consulter [Configuration des informations d'identification utilisateur pour les appareils Windows](device-config-setup.md#configure-windows-user-for-idt).
### Exception de signature non valide
Lorsque vous exécutez des tests de qualification Lambda, vous pouvez rencontrer l'`invalidsignatureexception`erreur si votre machine hôte IDT rencontre des problèmes d'accès au réseau. Réinitialisez votre routeur et relancez les tests.
### Erreurs de qualification liées à l'apprentissage automatique
Lorsque vous exécutez des tests de qualification de machine learning (ML), vous risquez de rencontrer des échecs de qualification si votre appareil ne répond pas aux [exigences](dlr-component.md#dlr-component-requirements) pour déployer les composants ML AWS fournis. Pour résoudre les erreurs de qualification ML, procédez comme suit :
+ Recherchez les détails des erreurs dans les journaux des composants déployés lors du test. Les journaux des composants se trouvent dans le `{{}}/results/{{}}/logs/{{}}` répertoire.
+ Ajoutez l'`-Dgg.persist=installed.software`argument au `test.json` fichier pour le scénario de test qui a échoué. Le `test.json` fichier se trouve dans `{{}}/tests/GGV2Q_{{version}} directory. `
### Les déploiements d'Open Test Framework (OTF) ont échoué
Si les tests OTF ne parviennent pas à terminer le déploiement, cela peut être dû aux autorisations définies pour le dossier parent de `TempResourcesDirOnDevice` et`InstallationDirRootOnDevice`. Pour définir correctement les autorisations de ce dossier, exécutez la commande suivante. Remplacez `{{folder-name}}` par le nom du dossier parent.
```
sudo chmod 755 {{folder-name}}
```
### Erreurs d'analyse
Les fautes de frappe dans une configuration JSON peuvent entraîner des erreurs d'analyse. La plupart du temps, le problème est lié à l'absence d'une virgule, d'une apostrophe ou d'un crochet dans le fichier JSON. IDT effectue la validation JSON et imprime les informations de débogage. Il imprime la ligne dans laquelle l'erreur s'est produite, le numéro de ligne et le numéro de colonne de l'erreur de syntaxe. Ces informations devraient être suffisantes pour vous aider à corriger l'erreur, mais si vous ne trouvez toujours pas l'erreur, vous pouvez effectuer la validation manuellement dans votre IDE, un éditeur de texte tel qu'Atom ou Sublime, ou via un outil en ligne tel que JSONLint.
### Erreurs de type « Autorisation refusée »
IDT effectue des opérations sur différents répertoires et fichiers d'un appareil testé. Certaines de ces opérations nécessitent un accès racine. Pour automatiser ces opérations, IDT doit être en mesure d'exécuter des commandes avec la commande sudo sans avoir à saisir un mot de passe.
Suivez les étapes ci-après pour autoriser l'accès sudo sans saisie de mot de passe.
**Note**
`user` et `username` font référence à l'utilisateur SSH utilisé par IDT pour accéder à l'appareil testé.
1. Utilisez **sudo usermod -aG sudo {{}}** pour ajouter l'utilisateur SSH au groupe sudo.
1. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur.
1. Ouvrez le fichier `/etc/sudoers`, puis ajoutez la ligne suivante à la fin du fichier : `{{}} ALL=(ALL) NOPASSWD: ALL`
**Note**
En tant que bonne pratique, nous vous recommandons d'utiliser **sudo visudo** lorsque vous modifiez `/etc/sudoers`.
### Erreur lors de la génération du rapport de qualification
IDT prend en charge les quatre dernières `{{major}}.{{minor}}` versions de la suite de qualification AWS IoT Greengrass V2 (GGV2Q) pour générer des rapports de qualification que vous pouvez soumettre AWS Partner Network pour inclure vos appareils dans le catalogue d' AWS Partner appareils. Les versions antérieures de la suite de qualification ne génèrent pas de rapports de qualification.
Si vous avez des questions concernant la politique d'assistance, contactez [AWS Support](https://aws.amazon.com/contact-us/).
### Erreur liée à un paramètre obligatoire manquant
Lorsque IDT ajoute de nouvelles fonctionnalités, il peut introduire des modifications dans les fichiers de configuration. L'utilisation d'un ancien fichier de configuration peut corrompre votre configuration. Si tel est le cas, le fichier `{{}}.log` sous `/results/{{}}/logs` répertorie explicitement tous les paramètres manquants. IDT valide également vos schémas de fichiers de configuration JSON pour vérifier que vous utilisez la dernière version prise en charge.
### Exception de sécurité sur macOS
Lorsque vous exécutez IDT sur un ordinateur hôte macOS, il bloque l'exécution d'IDT. Pour exécuter IDT, accordez une exception de sécurité aux exécutables faisant partie de la fonctionnalité d'exécution IDT. Lorsque le message d'avertissement s'affiche sur votre ordinateur hôte, procédez comme suit pour chacun des exécutables applicables :
**Pour accorder une exception de sécurité aux exécutables IDT**
1. Sur l'ordinateur macOS, dans le menu Apple, ouvrez les **Préférences système**.
1. Choisissez **Sécurité et confidentialité**, puis dans l'onglet **Général**, cliquez sur l'icône représentant un cadenas pour modifier les paramètres de sécurité.
1. En cas de blocage`devicetester_mac_x86-64`, recherchez le message `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` et choisissez **Autoriser quand même**.
1. Reprenez les tests IDT jusqu'à ce que vous ayez vérifié tous les exécutables concernés.
### Erreurs de connexion SSH
Lorsqu'IDT ne parvient pas à se connecter à un appareil testé, il enregistre les échecs de connexion. `/results/{{}}/logs/{{}}.log` Les messages SSH apparaissent en haut de ce fichier journal car la connexion à un appareil testé est l'une des premières opérations effectuées par IDT.
La plupart des configurations Windows utilisent l'application de TTy terminal Pu pour se connecter aux hôtes Linux. Cette application nécessite que vous convertissiez les fichiers de clé privée PEM standard dans un format Windows propriétaire appelé PPK. Si vous configurez SSH dans votre `device.json` fichier, utilisez des fichiers PEM. Si vous utilisez un fichier PPK, IDT ne peut pas créer de connexion SSH avec le AWS IoT Greengrass périphérique et ne peut pas exécuter de tests.
À partir de IDT v4.4.0, si vous n'avez pas activé le SFTP sur votre appareil testé, l'erreur suivante peut s'afficher dans le fichier journal.
```
SSH connection failed with EOF
```
Pour résoudre cette erreur, activez le protocole SFTP sur votre appareil.
### Erreurs de qualification du gestionnaire de flux
Lorsque vous exécutez des tests de qualification du gestionnaire de flux, l'erreur suivante peut s'afficher dans le `com.aws.StreamManagerExport.log` fichier.
```
Failed to upload data to S3
```
Cette erreur peut se produire lorsque le gestionnaire de flux utilise les AWS informations d'identification du `~/root/.aws/credentials` fichier sur votre appareil au lieu d'utiliser les informations d'identification de l'environnement qu'IDT exporte vers l'appareil testé. Pour éviter ce problème, supprimez le `credentials` fichier sur votre appareil et relancez le test de qualification.
### Erreurs de délai d'attente
Vous pouvez augmenter le délai d'expiration de chaque test en spécifiant un multiplicateur de délai appliqué à la valeur par défaut du délai d'expiration de chaque test. Toute valeur configurée pour cet indicateur doit être supérieure ou égale à 1.0.
Pour utiliser le multiplicateur de délai d'attente, utilisez l'indicateur `--timeout-multiplier` lors de l'exécution de tests. Par exemple :
```
./devicetester_linux run-suite --suite-id GGV2Q_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5
```
Pour de plus amples informations, exécutez `run-suite --help`.
Certaines erreurs de temporisation se produisent lorsque les scénarios de test IDT ne peuvent pas être terminés en raison de problèmes de configuration. Vous ne pouvez pas résoudre ces erreurs en augmentant le multiplicateur du délai d'expiration. Utilisez les journaux du test pour résoudre les problèmes de configuration sous-jacents.
+ Si les journaux des composants MQTT ou Lambda `Access denied` contiennent des erreurs, il est possible que votre dossier d'installation Greengrass ne dispose pas des autorisations de fichier correctes. Exécutez la commande suivante pour chaque dossier du chemin d'installation que vous avez défini dans votre `userdata.json` fichier.
```
sudo chmod 755 {{folder-name}}
```
+ Si les journaux de Greengrass indiquent que le déploiement de la CLI Greengrass n'est pas terminé, procédez comme suit :
+ Vérifiez qu'`bash`il est installé sur le périphérique testé.
+ Si votre `userdata.json` fichier inclut le paramètre `GreengrassCliVersion` de configuration, supprimez-le. Ce paramètre est obsolète dans IDT v4.1.0 et versions ultérieures. Pour de plus amples informations, veuillez consulter [Configurer userdata.json](set-config.md#userdata-config).
+ Si le test de déploiement Lambda a échoué avec le message d'erreur « Validation de la publication Lambda : expiration du délai » et que vous recevez une erreur dans le fichier journal de test `idt-gg2-lambda-function-idt-{{}}.log` () `Error: Could not find or load main class com.amazonaws.greengrass.runtime.LambdaRuntime.` indiquant que vous devez procéder comme suit :
+ Vérifiez le dossier utilisé `InstallationDirRootOnDevice` dans le `userdata.json` fichier.
+ Assurez-vous que les autorisations utilisateur appropriées sont configurées sur votre appareil. Pour plus de détails, consultez [Configurer les autorisations utilisateur sur votre appareil](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-config-setup.html#root-access).
### Erreurs de vérification de version
IDT émet l'erreur suivante lorsque les informations AWS d'identification de l'utilisateur IDT ne disposent pas des autorisations IAM requises.
```
Failed to check version compatibility
```
L' AWS utilisateur qui ne dispose pas des autorisations IAM requises.