Résolution des problèmes liés à IDT pourAWS IoT GreengrassV2 - AWS IoT Greengrass

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 pourAWS IoT GreengrassV2

IDT pourAWS IoT GreengrassLa 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.xmlcontient 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<device-tester-extract-location>/results/<execution-id>/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 Des journaux détaillés pourAWS IoT GreengrassLogiciel de base. IDT copie ce fichier depuis le périphérique testé lorsqu'il exécute des tests qui installentAWS IoT GreengrassLogiciel de base de l'appareil. Pour plus d'informations sur les messages contenus dans ce fichier journal, voirRésolution des problèmes AWS IoT Greengrass V2.
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, voirRésolution des problèmes AWS IoT Greengrass V2.

Résolution de l'IDT pourAWS IoT GreengrassErreurs V2

Avant d'exécuter IDT pourAWS IoT Greengrass, mettez en place 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.

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 danstest_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 votredevice.jsonetuserdata.json contiennent les informations correctes requises pour votre suite de tests. Pour plus d'informations sur la configuration requise pourAWS IoT Greengrassqualification, voirConfigurer les paramètres IDT pour exécuter la suite de AWS IoT Greengrass qualification.

Erreurs liées aux conflits

L'erreur suivante peut s'afficher lorsque vous exécutez leAWS IoT Greengrasssuite de qualifications 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 leAWS IoT Greengrasssuite de qualifications. 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 fait référence au nom du pool directement depuis votredevice.jsonfichier.

  • 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 leamazon/amazon-ec2-metadata-mockimage du 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é leamazon/amazon-ec2-metadata-mockconteneur 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 leFailed to read credentialerreur dans legreengrass.logfichier 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 plus d'informations, veuillez consulter Configuration des informations d'identification utilisateur pour les appareils Windows.

Erreurs de guidage avec PreInstalled Herbe verte

Lors de l'exécution d'IDT avec PreInstalled Greengrass, si vous rencontrez une erreur deGuiceouErrorInCustomProvider, vérifiez si le fichieruserdata.jsonpossède leInstalledDirRootOnDevicedéfini dans le dossier d'installation de Greengrass. IDT vérifie la présence du fichiereffectiveConfig.yamlsous<InstallationDirRootOnDevice>/config/effectiveConfig.yaml.

Pour plus d'informations, veuillez consulter Configuration des informations d'identification utilisateur pour les appareils Windows.

Exception de signature non valide

Lorsque vous exécutez des tests de qualification Lambda, vous pouvez rencontrer leinvalidsignatureexceptionerreur 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 pour le machine learning (ML), vous risquez de rencontrer des échecs de qualification si votre appareil ne répond pas auxexigencespour déployer leAWS-composants ML 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<device-tester-extract-location>/results/<execution-id>/logs/<test-group-id>annuaire.

  • Ajoutez le-Dgg.persist=installed.softwareargument en faveur dutest.jsonfichier pour le scénario de test défaillant. Letest.jsonle fichier se trouve dans le<device-tester-extract-location>/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 deTempResourcesDirOnDeviceetInstallationDirRootOnDevice. Pour définir correctement les autorisations de ce dossier, exécutez la commande suivante. Remplacerfolder-nameavec 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 parvenez toujours pas à la localiser, 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 <ssh-username> pour ajouter l'utilisateur SSH au groupe sudo.

  2. Déconnectez-vous, puis reconnectez-vous pour que les modifications entrent en vigueur.

  3. Ouvrez le fichier /etc/sudoers, puis ajoutez la ligne suivante à la fin du fichier : <ssh-username> 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 soutient les quatre dernièresmajor.minorversions duAWS IoT GreengrassSuite de qualification V2 (GGV2Q) pour générer des rapports de qualification que vous pouvez soumettre àAWS Partner Networkpour inclure vos appareils dans leAWS PartnerCatalogue d'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, contactezAWS Support.

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 <test_case_id>.log sous /results/<execution-id>/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, ouvrezPréférences du système.

  2. ChoisissezSécurité et confidentialité, puis sur leGénéralonglet, cliquez sur l'icône représentant un cadenas pour modifier les paramètres de sécurité.

  3. En cas de blocagedevicetester_mac_x86-64, recherchez le message"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.et choisissezAutoriser quand même.

  4. Reprenez les tests IDT jusqu'à ce que vous ayez vérifié tous les exécutables concernés.

Erreurs de connexion SSH

Lorsque IDT ne parvient pas à se connecter à un appareil testé, il enregistre les échecs de connexion dans/results/<execution-id>/logs/<test-case-id>.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 terminal PuTTY 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 votredevice.jsonfichier, utilisez des fichiers PEM. Si vous utilisez un fichier PPK, IDT ne peut pas créer de connexion SSH avecAWS IoT Greengrassappareil et impossible d'exécuter des 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 danscom.aws.StreamManagerExport.logfichier.

Failed to upload data to S3

Cette erreur peut se produire lorsque le gestionnaire de flux utilise leAWSinformations d'identification dans le~/root/.aws/credentialsfichier 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 lecredentialsarchivez 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 contiennentAccess deniederreurs, votre dossier d'installation Greengrass ne dispose peut-être pas des autorisations de fichier correctes. Exécutez la commande suivante pour chaque dossier du chemin d'installation que vous avez défini dans votreuserdata.jsonfichier.

    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 quebashest installé sur le périphérique testé.

    • Si votreuserdata.jsonle fichier inclut leGreengrassCliVersionparamètre de configuration, supprimez-le. Ce paramètre est obsolète dans IDT v4.1.0 et versions ultérieures. Pour plus d'informations, veuillez consulter Configurer userdata.json.

  • 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 du test (idt-gg2-lambda-function-idt-<resource-id>.log) qui ditError: Could not find or load main class com.amazonaws.greengrass.runtime.LambdaRuntime., procédez comme suit :

Erreurs de vérification de version

IDT émet l'erreur suivante lorsqueAWSles informations d'identification de l'utilisateur IDT ne disposent pas des autorisations IAM requises.

Failed to check version compatibility

LeAWSutilisateur ne disposant pas des autorisations IAM requises.