Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Problembehandlung IDT für V2 AWS IoT Greengrass
IDT für AWS IoT Greengrass V2 schreibt Fehler je nach Art der Fehler an verschiedene Speicherorte. IDT schreibt Fehler in die Konsole, in Protokolldateien und in Testberichte.
## Wo kann man nach Fehlern suchen
Allgemeine Fehler werden auf der Konsole angezeigt, während der Test ausgeführt wird, und eine Zusammenfassung der fehlgeschlagenen Tests wird angezeigt, wenn alle Tests abgeschlossen sind. `awsiotdevicetester_report.xml`enthält eine Zusammenfassung aller Fehler, die zum Fehlschlagen eines Tests geführt haben. IDT speichert die Protokolldateien für jeden Testlauf in einem Verzeichnis mit einer UUID für die Testausführung, die während des Testlaufs auf der Konsole angezeigt wird.
Das Verzeichnis der IDT-Testprotokolle ist. `/results//logs/` Dieses Verzeichnis enthält die folgenden Dateien, die in der Tabelle angezeigt werden. Dies ist beim Debuggen nützlich.
| Datei | Description |
| --- | --- |
| test\$1manager.log | Die Protokolle, die während der Ausführung des Tests auf die Konsole geschrieben wurden. Die Zusammenfassung der Ergebnisse am Ende dieser Datei enthält eine Liste der fehlgeschlagenen Tests. Die Warn- und Fehlerprotokolle in dieser Datei können Ihnen Informationen über den/die Fehler bereitstellen. |
| test-group-id/test-case-id/test-name.log | Detaillierte Protokolle für den spezifischen Test in einer Testgruppe. Für Tests, die Greengrass-Komponenten bereitstellen, wird die Testfall-Protokolldatei aufgerufengreengrass-test-run.log. |
| test-group-id/test-case-id/greengrass.log | Detaillierte Protokolle für die AWS IoT Greengrass Core-Software. IDT kopiert diese Datei von dem zu testenden Gerät, wenn es Tests ausführt, bei denen AWS IoT Greengrass Core-Software auf dem Gerät installiert wird. Weitere Informationen zu den Meldungen in dieser Protokolldatei finden Sie unter[Problembehebung AWS IoT Greengrass V2](troubleshooting.md). |
| test-group-id/test-case-id/component-name.log | Detaillierte Protokolle für Greengrass-Komponenten, die während Testläufen eingesetzt werden. IDT kopiert Komponenten-Protokolldateien vom zu testenden Gerät, wenn Tests ausgeführt werden, bei denen bestimmte Komponenten bereitgestellt werden. Der Name jeder Komponenten-Protokolldatei entspricht dem Namen der bereitgestellten Komponente. Weitere Hinweise zu den Meldungen in dieser Protokolldatei finden Sie unter[Problembehebung AWS IoT Greengrass V2](troubleshooting.md). |
## IDT für AWS IoT Greengrass V2-Fehler beheben
Bevor Sie IDT for ausführen AWS IoT Greengrass, sollten Sie die richtigen Konfigurationsdateien einrichten. Wenn Sie Parsing- und Konfigurationsfehler erhalten, besteht Ihr erster Schritt darin, eine für Ihre Umgebung geeignete Konfigurationsvorlage zu finden und zu verwenden.
Wenn weiterhin Probleme auftreten, beachten Sie den folgenden Debugging-Vorgang.
**Topics**
+ [Fehler bei der Alias-Auflösung](#alias-resolution-errors)
+ [Konfliktfehler](#conflict-error)
+ [Fehler aufgrund eines nicht startenden Tests](#could-not-start-test)
+ [Das Docker-Qualifikationsbild ist vorhanden, Fehler](#docker-qualification-image-exists)
+ [Die Anmeldeinformationen konnten nicht gelesen werden](#failed-to-read-credential-windows)
+ [Guide-Fehler mit Greengrass PreInstalled](#guice-errors)
+ [Ungültige Signaturausnahme](#invalid-signature-exception-lambda)
+ [Qualifizierungsfehler beim maschinellen Lernen](#machine-learning-qualification-failure)
+ [Fehlgeschlagene Bereitstellungen von Open Test Framework (OTF)](#otf-deployment-failure)
+ [Parsing-Fehler](#parse-error)
+ [Fehler bei abgelehnter Berechtigung](#permission-denied-pwd-sudo)
+ [Fehler beim Generieren des Qualifizierungsberichts](#qualification-report-policy-error)
+ [Fehler aufgrund fehlender erforderlicher Parameter](#required-param-missing)
+ [Sicherheitsausnahme auf macOS](#security-exception-macos)
+ [SSH-Verbindungsfehler](#ssh-connect-errors)
+ [Qualifizierungsfehler im Stream Manager](#stream-manager-qualification-failure)
+ [Timeout-Fehler](#test-timeout)
+ [Fehler bei der Versionsprüfung](#version-compatibility-check-failure)
### Fehler bei der Alias-Auflösung
Wenn Sie benutzerdefinierte Testsuiten ausführen, wird möglicherweise der folgende Fehler in der Konsole und in der angezeigt`test_manager.log`.
```
Couldn't resolve placeholders: couldn't do a json lookup: index out of range
```
Dieser Fehler kann auftreten, wenn die im IDT Test Orchestrator konfigurierten Aliase nicht korrekt aufgelöst werden oder wenn die aufgelösten Werte nicht in den Konfigurationsdateien vorhanden sind. Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihr `device.json` und die richtigen Informationen `userdata.json ` enthalten, die für Ihre Testsuite erforderlich sind. Informationen zur Konfiguration, die für die AWS IoT Greengrass Qualifizierung erforderlich ist, finden Sie unter[Konfigurieren Sie die IDT-Einstellungen, um die AWS IoT Greengrass Qualification Suite auszuführen](set-config.md).
### Konfliktfehler
Möglicherweise wird der folgende Fehler angezeigt, wenn Sie die AWS IoT Greengrass Qualification Suite gleichzeitig auf mehr als einem Gerät ausführen.
```
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]” }
```
Die gleichzeitige Testausführung wird für die AWS IoT Greengrass Qualification Suite noch nicht unterstützt. Führen Sie die Qualification Suite nacheinander für jedes Gerät aus.
### Fehler aufgrund eines nicht startenden Tests
Möglicherweise treten Fehler auf, die auf Fehler hinweisen, die beim Versuch, den Test zu starten, aufgetreten sind. Es gibt mehrere mögliche Ursachen. Gehen Sie daher wie folgt vor:
+ Stellen Sie sicher, dass der Poolname in Ihrem Ausführungsbefehl tatsächlich existiert. IDT verweist direkt aus Ihrer `device.json` Datei auf den Poolnamen.
+ Stellen Sie sicher, dass die Geräte in Ihrem Pool über die richtigen Konfigurationsparameter verfügen.
### Das Docker-Qualifikationsbild ist vorhanden, Fehler
Die Qualifizierungstests für Docker Application Manager verwenden das `amazon/amazon-ec2-metadata-mock` Container-Image in Amazon ECR, um das zu testende Gerät zu qualifizieren.
Möglicherweise wird die folgende Fehlermeldung angezeigt, wenn das Image bereits in einem Docker-Container auf dem zu testenden Gerät vorhanden ist.
```
The Docker image amazon/amazon-ec2-metadata-mock:version already exists on the device.
```
Wenn Sie dieses Image bereits heruntergeladen und den `amazon/amazon-ec2-metadata-mock` Container auf Ihrem Gerät ausgeführt haben, stellen Sie sicher, dass Sie dieses Image von dem zu testenden Gerät entfernen, bevor Sie die Qualifizierungstests ausführen.
### Die Anmeldeinformationen konnten nicht gelesen werden
Beim Testen von Windows-Geräten kann der `Failed to read credential` Fehler in der `greengrass.log` Datei auftreten, wenn der Benutzer, den Sie für die Verbindung mit dem zu testenden Gerät verwenden, nicht im Anmeldeinformationsmanager auf diesem Gerät eingerichtet ist.
Um diesen Fehler zu beheben, konfigurieren Sie den Benutzer und das Passwort für den IDT-Benutzer im Anmeldeinformationsmanager auf dem zu testenden Gerät.
Weitere Informationen finden Sie unter [Konfigurieren Sie Benutzeranmeldeinformationen für Windows-Geräte](device-config-setup.md#configure-windows-user-for-idt).
### Guide-Fehler mit Greengrass PreInstalled
Wenn Sie beim Ausführen von IDT mit PreInstalled Greengrass auf den Fehler `Guice` oder stoßen`ErrorInCustomProvider`, überprüfen Sie, ob die Datei den `InstalledDirRootOnDevice` Greengrass-Installationsordner `userdata.json` enthält. IDT sucht nach der Datei unter. `effectiveConfig.yaml` `/config/effectiveConfig.yaml`
Weitere Informationen finden Sie unter [Konfigurieren Sie Benutzeranmeldeinformationen für Windows-Geräte](device-config-setup.md#configure-windows-user-for-idt).
### Ungültige Signaturausnahme
Wenn Sie Lambda-Qualifizierungstests ausführen, kann der `invalidsignatureexception` Fehler auftreten, wenn auf Ihrem IDT-Hostcomputer Netzwerkzugriffsprobleme auftreten. Setzen Sie Ihren Router zurück und führen Sie die Tests erneut aus.
### Qualifizierungsfehler beim maschinellen Lernen
Wenn Sie Qualifizierungstests für maschinelles Lernen (ML) durchführen, kann es zu Qualifizierungsfehlern kommen, wenn Ihr Gerät die [Anforderungen](dlr-component.md#dlr-component-requirements) für die Bereitstellung der AWS bereitgestellten ML-Komponenten nicht erfüllt. Gehen Sie wie folgt vor, um ML-Qualifizierungsfehler zu beheben:
+ Suchen Sie in den Komponentenprotokollen nach Fehlerdetails für die Komponenten, die während des Testlaufs bereitgestellt wurden. Die Komponentenprotokolle befinden sich im `/results//logs/` Verzeichnis.
+ Fügen Sie der `test.json` Datei das `-Dgg.persist=installed.software` Argument für den fehlgeschlagenen Testfall hinzu. Die `test.json` Datei befindet sich im `/tests/GGV2Q_version directory. `
### Fehlgeschlagene Bereitstellungen von Open Test Framework (OTF)
Wenn die Bereitstellung durch OTF-Tests nicht abgeschlossen werden kann, kann dies wahrscheinlich an den für den übergeordneten Ordner von `TempResourcesDirOnDevice` und `InstallationDirRootOnDevice` festgelegten Berechtigungen liegen. Führen Sie den folgenden Befehl aus, um die Berechtigungen für diesen Ordner korrekt festzulegen. `folder-name`Ersetzen Sie ihn durch den Namen des übergeordneten Ordners.
```
sudo chmod 755 folder-name
```
### Parsing-Fehler
Tippfehler in einer JSON-Konfiguration können zu Analysefehlern führen. In den meisten Fällen sind die Ursache des Problems ausgelassene Klammern, Kommas oder Anführungszeichen in Ihrer JSON-Datei. IDT führt eine JSON-Validierung durch und druckt Debugging-Informationen. Gedruckt werden die Zeile, in der der Fehler aufgetreten ist, sowie Zeilennummer und Spaltennummer des Syntaxfehlers. Diese Informationen sollten ausreichen, um Ihnen bei der Behebung des Fehlers zu helfen. Wenn Sie den Fehler jedoch immer noch nicht finden können, können Sie die Validierung manuell in Ihrer IDE, einem Texteditor wie Atom oder Sublime oder über ein Online-Tool wie durchführen. JSONLint
### Fehler bei abgelehnter Berechtigung
IDT führt Operationen für verschiedene Verzeichnisse und Dateien auf einem zu testenden Gerät aus. Einige dieser Operationen erfordern Stammzugriff. Zum Automatisieren dieser Operationen muss IDT Befehle mit sudo ausführen können, ohne ein Passwort einzugeben.
Führen Sie die folgenden Schritte aus, um Sudo-Zugriff zu erteilen, ohne ein Passwort eingeben zu müssen.
**Anmerkung**
`user` und `username` beziehen sich auf den SSH-Benutzer, der von IDT für den Zugriff auf das zu testende Gerät verwendet wird.
1. Verwenden Sie **sudo usermod -aG sudo ****, um Ihren SSH-Benutzer zur sudo-Gruppe hinzuzufügen.
1. Melden Sie sich ab und melden Sie sich dann wieder an, damit die Änderungen wirksam werden.
1. Öffnen Sie die Datei `/etc/sudoers` und fügen Sie am Ende der Datei die folgende Zeile hinzu: ` ALL=(ALL) NOPASSWD: ALL`
**Anmerkung**
Als bewährte Methode empfehlen wir, dass Sie, **sudo visudo** verwenden, wenn Sie `/etc/sudoers` bearbeiten.
### Fehler beim Generieren des Qualifizierungsberichts
IDT unterstützt die vier neuesten `major.minor` Versionen der AWS IoT Greengrass V2 Qualification Suite (GGV2Q) zur Erstellung von Qualifizierungsberichten, die Sie einreichen können, AWS Partner Network um Ihre Geräte in den AWS Partner Gerätekatalog aufzunehmen. Frühere Versionen der Qualification Suite generieren keine Qualifikationsberichte.
Wenn Sie Fragen zu den Support-Richtlinien haben, wenden Sie sich an [AWS Support](https://aws.amazon.com/contact-us/).
### Fehler aufgrund fehlender erforderlicher Parameter
Wenn IDT neue Funktionen hinzufügt, kann es zu Änderungen an den Konfigurationsdateien kommen. Bei Verwendung einer alten Konfigurationsdatei kann Ihre Konfiguration beschädigt werden. In diesem Fall listet die Datei `.log` unter `/results//logs` ausdrücklich alle fehlenden Parameter auf. IDT validiert auch Ihre JSON-Konfigurationsdateischemas, um sicherzustellen, dass Sie die neueste unterstützte Version verwenden.
### Sicherheitsausnahme auf macOS
Wenn Sie IDT auf einem macOS-Hostcomputer ausführen, wird die Ausführung von IDT blockiert. Um IDT auszuführen, gewähren Sie den ausführbaren Dateien eine Sicherheitsausnahme, die Teil der IDT-Laufzeitfunktionalität ist. Wenn die Warnmeldung auf Ihrem Host-Computer angezeigt wird, gehen Sie für jede der entsprechenden ausführbaren Dateien wie folgt vor:
**Um ausführbaren IDT-Dateien eine Sicherheitsausnahme zu gewähren**
1. Öffnen Sie auf dem macOS-Computer im Apple-Menü die **Systemeinstellungen**.
1. Wählen Sie **Sicherheit und Datenschutz und** dann auf der Registerkarte **Allgemein** das Schlosssymbol, um Änderungen an den Sicherheitseinstellungen vorzunehmen.
1. Suchen Sie im Falle einer Blockierung `devicetester_mac_x86-64` nach der Nachricht `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` und wählen Sie „**Trotzdem zulassen**“.
1. Setzen Sie den IDT-Test fort, bis Sie alle beteiligten ausführbaren Dateien abgeschlossen haben.
### SSH-Verbindungsfehler
Wenn IDT keine Verbindung zu einem zu testenden Gerät herstellen kann, werden Verbindungsfehler protokolliert. `/results//logs/.log` SSH-Meldungen werden oben in dieser Protokolldatei angezeigt, da die Verbindung zu einem getesteten Gerät eine der ersten Operationen ist, die IDT ausführt.
Die meisten Windows-Konfigurationen verwenden die TTy Pu-Terminal-Anwendung, um eine Verbindung zu Linux-Hosts herzustellen. Für diese Anwendung müssen Sie standardmäßige private PEM-Schlüsseldateien in ein proprietäres Windows-Format namens PPK konvertieren. Wenn Sie SSH in Ihrer `device.json` Datei konfigurieren, verwenden Sie PEM-Dateien. Wenn Sie eine PPK-Datei verwenden, kann IDT keine SSH-Verbindung mit dem AWS IoT Greengrass Gerät herstellen und keine Tests ausführen.
Ab IDT v4.4.0 wird in der Protokolldatei möglicherweise der folgende Fehler angezeigt, wenn Sie SFTP auf Ihrem zu testenden Gerät nicht aktiviert haben.
```
SSH connection failed with EOF
```
Um diesen Fehler zu beheben, aktivieren Sie SFTP auf Ihrem Gerät.
### Qualifizierungsfehler im Stream Manager
Wenn Sie Stream Manager-Qualifizierungstests ausführen, wird möglicherweise der folgende Fehler in der `com.aws.StreamManagerExport.log` Datei angezeigt.
```
Failed to upload data to S3
```
Dieser Fehler kann auftreten, wenn Stream Manager die AWS Anmeldeinformationen in der `~/root/.aws/credentials` Datei auf Ihrem Gerät verwendet, anstatt die Umgebungsinformationen zu verwenden, die IDT auf das zu testende Gerät exportiert. Um dieses Problem zu vermeiden, löschen Sie die `credentials` Datei auf Ihrem Gerät und führen Sie den Qualifikationstest erneut aus.
### Timeout-Fehler
Sie können das Timeout für jeden Test erhöhen, indem Sie einen Timeout-Multiplikator angeben, der auf den Standardwert des Timeouts jedes Tests angewendet wird. Jeder Wert für dieses Kennzeichen muss größer als oder gleich 1,0 sein.
Um den Timeout-Multiplikator zu verwenden, verwenden Sie beim Ausführen des Tests das Flag `--timeout-multiplier`. Beispiel:
```
./devicetester_linux run-suite --suite-id GGV2Q_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5
```
Führen Sie `run-suite --help` aus, um weitere Informationen zu erhalten.
Einige Timeout-Fehler treten auf, wenn IDT-Testfälle aufgrund von Konfigurationsproblemen nicht abgeschlossen werden können. Sie können diese Fehler nicht beheben, indem Sie den Timeout-Multiplikator erhöhen. Verwenden Sie die Protokolle des Testlaufs, um die zugrunde liegenden Konfigurationsprobleme zu beheben.
+ Wenn die MQTT- oder Lambda-Komponentenprotokolle `Access denied` Fehler enthalten, verfügt Ihr Greengrass-Installationsordner möglicherweise nicht über die richtigen Dateiberechtigungen. Führen Sie den folgenden Befehl für jeden Ordner im Installationspfad aus, den Sie in Ihrer Datei definiert haben. `userdata.json`
```
sudo chmod 755 folder-name
```
+ Wenn die Greengrass-Protokolle darauf hinweisen, dass die Greengrass-CLI-Bereitstellung nicht abgeschlossen ist, gehen Sie wie folgt vor:
+ Stellen Sie sicher, dass `bash` es auf dem zu testenden Gerät installiert ist.
+ Wenn Ihre `userdata.json` Datei den `GreengrassCliVersion` Konfigurationsparameter enthält, entfernen Sie ihn. Dieser Parameter ist in IDT v4.1.0 und späteren Versionen veraltet. Weitere Informationen finden Sie unter [Konfigurieren Sie userdata.json](set-config.md#userdata-config).
+ Wenn der Lambda-Bereitstellungstest mit der Fehlermeldung „Validating Lambda publish: time out“ fehlschlug und Sie eine Fehlermeldung in der Testprotokolldatei (`idt-gg2-lambda-function-idt-.log`) erhalten, die besagt`Error: Could not find or load main class com.amazonaws.greengrass.runtime.LambdaRuntime.`, gehen Sie wie folgt vor:
+ Überprüfen Sie, für welchen Ordner `InstallationDirRootOnDevice` in der Datei verwendet wurde. `userdata.json`
+ Stellen Sie sicher, dass die richtigen Benutzerberechtigungen auf Ihrem Gerät eingerichtet sind. Weitere Informationen finden [Sie unter Benutzerberechtigungen auf Ihrem Gerät konfigurieren](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-config-setup.html#root-access).
### Fehler bei der Versionsprüfung
IDT gibt den folgenden Fehler aus, wenn die AWS Benutzeranmeldeinformationen für den IDT-Benutzer nicht über die erforderlichen IAM-Berechtigungen verfügen.
```
Failed to check version compatibility
```
Der AWS Benutzer, der nicht über die erforderlichen IAM-Berechtigungen verfügt.