AWS IoT Greengrass Version 1 trat am 30. Juni 2023 in die erweiterte Lebensphase ein. Weitere Informationen finden Sie in der AWS IoT Greengrass V1 Wartungsrichtlinie. Nach diesem Datum AWS IoT Greengrass V1 werden keine Updates mehr veröffentlicht, die Funktionen, Verbesserungen, Bugfixes oder Sicherheitspatches bieten. Geräte, die auf laufen, werden AWS IoT Greengrass V1 nicht gestört und funktionieren weiterhin und stellen eine Verbindung zur Cloud her. Wir empfehlen Ihnen dringend, zu migrieren AWS IoT Greengrass Version 2, da dies wichtige neue Funktionen und Unterstützung für zusätzliche Plattformen bietet.

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.

Fehlerbehebung für AWS IoT Greengrass

Dieser Abschnitt enthält Informationen zur Fehlerbehebung und zu möglichen Lösungen für Probleme mit AWS IoT Greengrass.

Weitere Informationen zu AWS IoT Greengrass-Kontingenten (Einschränkungen) finden Sie unter Servicekontingente in der Allgemeine Amazon Web Services-Referenz.

Probleme mit AWS IoT Greengrass Core

Wenn die AWS IoT Greengrass Core-Software nicht gestartet wird, führen Sie die folgenden allgemeinen Schritte zur Fehlerbehebung aus:

Durchsuchen Sie die folgenden Faktoren und Fehler, um Informationen zur Behebung von Problemen mit einem -AWS IoT GreengrassKern zu finden.

 

Fehler: In der Konfigurationsdatei fehlt CaPath, CertPath oder KeyPath. Der Greengrass-Daemon-Prozess mit [pid = <pid>] ist abgestürzt.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in crash.log angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Dies kann der Fall sein, wenn Sie Version 1.6 oder früher ausführen. Führen Sie eine der folgenden Aktionen aus:

 

Fehler: Fehler beim Analysieren von /<greengrass-root>/config/config.json.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Stellen Sie sicher, dass die Greengrass-Konfigurationsdatei ein gültiges JSON-Format verwendet.

Öffnen Sie config.json (im Verzeichnis /greengrass-root/config) und validieren Sie das JSON-Format. Stellen Sie z. B. sicher, dass Kommas korrekt verwendet werden.

 

Fehler: Beim Generieren der TLS-Konfiguration ist ein Fehler aufgetreten: ErrUnknownURIScheme

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Stellen Sie sicher, dass die Eigenschaften im Kryptobereich der Greengrass-Konfigurationsdatei gültig sind. Die Fehlermeldung sollte weitere Informationen enthalten.

Öffnen Sie config.json (in /greengrass-root/config) und überprüfen Sie den Abschnitt crypto. Beispielsweise müssen Zertifikat- und Schlüsselpfade das richtige URI-Format verwenden und auf den richtigen Speicherort verweisen.

 

Fehler: Laufzeit konnte nicht gestartet werden: Es konnten keine Worker gestartet werden: Zeitüberschreitung für den Container-Test.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Legen Sie die Eigenschaft postStartHealthCheckTimeout in der Greengrass-Konfigurationsdatei fest. Diese optionale Eigenschaft konfiguriert die Zeitspanne (in Millisekunden), die der Greengrass-Daemon auf das Ende der Zustandsprüfung nach dem Start wartet. Der Standardwert ist 30 Sekunden (30.000 ms).

Öffnen Sie config.json (im Verzeichnis /greengrass-root/config). Fügen Sie im Objekt runtime die Eigenschaft postStartHealthCheckTimeout hinzu und stellen Sie den Wert auf eine Zahl größer als 30000 ein. Fügen Sie gegebenenfalls ein Komma ein, um eine gültige JSON-Datei zu erstellen. Beispielsweise:

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

 

Fehler: Auf lokaler Cloudwatch konnte logGroup nicht aufgerufen PutLogEvents werden: /GreengrassSystem/connection_manager, Fehler: RequestError: Anforderung fehlgeschlagen gesendet durch: Post http://<path>/cloudwatch/logs/: dial tcp <address>: getsockopt: Verbindung verweigert, Antwort: { }.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Dies kann der Fall sein, wenn Sie AWS IoT Greengrass auf einem Raspberry Pi ausführen und die erforderliche Speichereinrichtung nicht abgeschlossen wurde. Weitere Informationen finden Sie in diesem Schritt.

 

Fehler: Server kann nicht erstellt werden, da: chmod /<greengrass-root>/ggc/deployment/lambda/arn:aws:lambda:<region>:<account-id>:function:<function-name>:<version>/<file-name>: keine solche Datei oder kein solches Verzeichnis vorhanden ist.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Wenn Sie eine Lambda-ausführbare Datei im Kern bereitgestellt haben, überprüfen Sie die -HandlerEigenschaft der Funktion in der -group.jsonDatei (in /greengrass-root /ggc/deployment/group). Wenn der Handler nicht genau dem Namen Ihrer kompilierten ausführbaren Datei entspricht, ersetzen Sie den Inhalt der Datei group.json durch ein leeres JSON-Objekt ({}) und führen Sie die folgenden Befehle zum Starten von AWS IoT Greengrass aus:

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

Verwenden Sie dann die AWS Lambda-API, um den handler-Parameter der Funktionskonfiguration zu aktualisieren, eine neue Funktionsversion zu veröffentlichen und den Alias zu aktualisieren. Weitere Informationen finden Sie unter AWS Lambda-Funktionsversionen und -Aliase.

Vorausgesetzt, Sie haben die Funktion Ihrer Greengrass-Gruppe per Alias hinzugefügt (empfohlen), können Sie Ihre Gruppe jetzt erneut bereitstellen. (Ist dies nicht der Fall, müssen Sie auf die neue Version oder den Alias der Funktion in Ihrer Gruppendefinition und Ihren Abonnements verweisen, bevor Sie die Gruppe bereitstellen).

 

Die AWS IoT Greengrass Core-Software wird nicht gestartet, nachdem Sie von der Ausführung ohne Containerisierung zur Ausführung in einem Greengrass-Container gewechselt sind.

Lösung: Prüfen Sie, ob Container-Abhängigkeiten fehlen.

 

Fehler: Spulengröße sollte mindestens 262144 Bytes betragen.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Öffnen Sie die Datei group.json (im Verzeichnis /greengrass-root/ggc/deployment/group), ersetzen Sie den Inhalt der Datei mit einem leeren JSON-Objekt ({}) und führen Sie die folgenden Befehle aus, um AWS IoT Greengrass zu starten:

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

Anschließend befolgen Sie die Schritte im Verfahren So speichern Sie Nachrichten im lokalen Speicher. Stellen Sie für die GGCloudSpooler-Funktion sicher, dass Sie einen GG_CONFIG_MAX_SIZE_BYTES-Wert angeben, der größer als oder gleich 262144.

 

Fehler: [ERROR]-Cloud messaging error: Error occurred while trying to publish a message. {„errorString“: „operation timed out“} (Cloud Messaging Fehler: Fehler trat beim Versuch zur Veröffentlichung einer Nachricht auf)

Lösung: Möglicherweise wird dieser Fehler in GGCloudSpooler.log angezeigt, wenn der Greengrass-Core keine MQTT-Nachrichten an AWS IoT Core senden kann. Dies kann auftreten, wenn die Core-Umgebung eine begrenzte Bandbreite und eine hohe Latenz aufweist. Wenn Sie AWS IoT Greengrass Version 1.10.2 oder höher ausführen, versuchen Sie, den mqttOperationTimeout-Wert in der Datei config.json zu erhöhen. Wenn die Eigenschaft nicht vorhanden ist, fügen Sie sie dem coreThing-Objekt hinzu. Beispielsweise:

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

Der Standardwert ist 5, und der Mindestwert ist 5.

 

Fehler: container_linux.go:344: Start des Container-Prozesses verursachte „process_linux.go:424: container init caused \"rootfs_linux.go:64: mounting \\\"/greengrass/ggc/socket/greengrass_ipc.sock\\\" to rootfs \\\"/greengrass/ggc/packages/<version>/rootfs/merged\\\" at \\\"/greengrass_ipc.sock\\\" caused \\\"stat /greengrass/ggc/socket/greengrass_ipc.sock: permission denied\\\"\"“.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in runtime.log angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Dies tritt auf, wenn Ihr umask höher ist als 0022. Sie müssen umask auf 0022 oder niedriger festlegen, um das Problem zu beheben. Ein Wert von 0022 gewährt standardmäßig jeder Person Leseberechtigung für neue Dateien.

 

Fehler: Greengrass-Daemon wird mit folgender PID ausgeführt: <process-id>. Einige Systemkomponenten konnten nicht gestartet werden. Überprüfen Sie die Datei „'runtime.log“ auf Fehler.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Überprüfen Sie runtime.log und crash.log auf spezifische Fehlerinformationen. Weitere Informationen finden Sie unter Fehlerbehebung mit Protokollen.

 

Der Geräteschatten wird nicht mit der Cloud synchronisiert.

Lösung: Stellen Sie sicher, dass AWS IoT Greengrass Berechtigungen für die Aktionen iot:UpdateThingShadow und iot:GetThingShadow in der Greengrass-Servicerolle besitzen. Wenn die Servicerolle die verwaltete Richtlinie AWSGreengrassResourceAccessRolePolicy verwendet, sind diese Berechtigungen standardmäßig enthalten.

Siehe Beheben von Timeout-Problemen während der Schattensynchronisierung.

 

FEHLER: TCP-Verbindung kann nicht angenommen werden. accept tcp [::]:8000: accept4: zu viele geöffnete Dateien.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in der greengrassd-Skriptausgabe angezeigt. Dies kann auftreten, wenn das Dateideskriptor-Limit für die AWS IoT Greengrass Core-Software den Schwellenwert erreicht hat und erhöht werden muss.

Verwenden Sie den folgenden Befehl und starten Sie anschließend die AWS IoT Greengrass Core-Software neu.

ulimit -n 2048

 

Fehler: Laufzeit-Ausführungsfehler: Lambda-Container kann nicht gestartet werden. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:50: preparing rootfs caused \\\"permission denied\\\"\"".

Lösung: Installieren Sie AWS IoT Greengrass direkt im Stammverzeichnis oder stellen Sie sicher, dass das Verzeichnis, in dem die AWS IoT Greengrass Core-Software und ihre übergeordneten Verzeichnisse installiert sind, allen Benutzern execute-Berechtigungen erteilen.

 

Warnung: [WARN]-[5]GK Remote: Fehler beim Abrufen von öffentlichen Schlüsseldaten: ErrPrincipalNotConfigured: privater Schlüssel für MqttCertificate ist nicht festgelegt.

Lösung: AWS IoT Greengrass verwendet einen gemeinsamen Handler zum Validieren der Eigenschaften aller Sicherheitsprinzipale. Diese Warnmeldung in runtime.log wird erwartet, es sei denn, Sie haben einen benutzerdefinierten privaten Schlüssel für den lokalen MQTT-Server angegeben. Weitere Informationen finden Sie unter AWS IoT Greengrass Kernsicherheitsprinzipale.

 

Fehler: Berechtigung verweigert, wenn Sie versuchen, die Rolle arn:aws:iam::<account-id>:role/<role-name> zu verwenden, um auf s3 url https://<region>-greengrass-updates.s3.<region>.amazonaws.com/core/<architecture>/greengrass-core-<distribution-version>.tar.gz zuzugreifen.

Lösung: Dieser Fehler wird möglicherweise angezeigt, wenn ein over-the-air (OTA)-Update fehlschlägt. Fügen Sie in der Richtlinie der Unterzeichnerrolle das Ziel AWS-Region als hinzuResource. Diese Signer-Rolle wird zum Vorsignieren der S3-URL zur Aktualisierung der AWS IoT Greengrass-Software verwendet. Weitere Informationen finden Sie unter S3-URL-Signer-Rolle.

 

Der -AWS IoT GreengrassKern ist für die Verwendung eines Netzwerk-Proxys konfiguriert und Ihre Lambda-Funktion kann keine ausgehenden Verbindungen herstellen.

Lösung: Abhängig von Ihrer Laufzeit und den ausführbaren Dateien, die von der Lambda-Funktion zum Erstellen von Verbindungen verwendet werden, erhalten Sie möglicherweise auch Verbindungs-Timeout-Fehler. Stellen Sie sicher, dass Ihre Lambda-Funktionen die entsprechende Proxy-Konfiguration verwendenhttp_proxy, um eine Verbindung über den Netzwerk-Proxy herzustellen. AWS IoT Greengrass übergibt die Proxy-Konfiguration an benutzerdefinierte Lambda-Funktionen über die no_proxy Umgebungsvariablen https_proxy, und . Sie können, wie im folgenden Python-Ausschnitt gezeigt, aufgerufen werden.

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

Verwenden Sie die gleiche Groß-/Kleinschreibung wie die Variable, die in Ihrer Umgebung definiert ist, z. B. nur Kleinbuchstaben (http_proxy) oder nur Großbuchstaben (HTTP_PROXY). Für diese Variablen unterstützt AWS IoT Greengrass beides.

 

Der Core befindet sich in einer unendlichen Verbinden-Trennen-Schleife. Die Datei „runtime.log“ enthält eine fortlaufende Reihe von Verbinden- und Trennen-Einträgen.

Lösung: Dies kann auftreten, wenn ein anderes Gerät für die Verwendung des Core-Dingnamens als Client-ID für MQTT-Verbindungen mit AWS IoT hartkodiert ist. Gleichzeitige Verbindungen im selben AWS-Region und AWS-Konto müssen eindeutige Client-IDs verwenden. Standardmäßig verwendet der Kern den Core-Objektnamen als Client-ID für diese Verbindungen.

Zur Behebung dieses Problems können Sie die Client-ID ändern, die vom anderen Gerät für die Verbindung verwendet wird (empfohlen) oder den Standardwert für den Core überschreiben.

 

Fehler: Lambda-Container kann nicht gestartet werden. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:62: mounting \\\"proc\\\" to rootfs \\\"

Lösung: Auf einigen Plattformen wird dieser Fehler möglicherweise in angezeigt, runtime.log wenn AWS IoT Greengrass versucht, das /proc Dateisystem zu mounten, um einen Lambda-Container zu erstellen. Oder Sie sehen möglicherweise ähnliche Fehler, wie z. B. operation not permitted oder EPERM. Diese Fehler können auch dann auftreten, wenn Tests auf der Plattform durch das Skript des Abhängigkeitenprüfers ausgeführt werden.

Probieren Sie eine der folgenden möglichen Lösungen aus:

 

[ERROR]-Laufzeitausführungsfehler: Lambda-Container konnte nicht gestartet werden. {"errorString ": "Container-Mounts konnten nicht initialisiert werden: Greengrass-Root konnte in der Overlay-Oberseite nicht maskiert werden: Maskgerät konnte nicht im Verzeichnis <ggc-path>: Datei existiert"}

Lösung: Dieser Fehler wird möglicherweise in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Dieser Fehler tritt auf, wenn eine Lambda-Funktion in der AWS IoT Greengrass Gruppe nicht auf das /usr Verzeichnis im Dateisystem des Kerns zugreifen kann.

Um dieses Problem zu beheben, fügen Sie der Gruppe eine lokale Volume-Ressource hinzu und stellen Sie dann die Gruppe bereit. Diese Ressource muss:

 

[ERROR]-Deployment fehlgeschlagen. {"deploymentId ": "<deployment-id>", "errorString": "Container-Testprozess mit pid <pid> fehlgeschlagen: Container-Prozessstatus: Beendigungsstatus 1"}

Lösung: Dieser Fehler wird möglicherweise in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Dieser Fehler tritt auf, wenn eine Lambda-Funktion in der AWS IoT Greengrass Gruppe nicht auf das /usr Verzeichnis im Dateisystem des Kerns zugreifen kann.

Sie können bestätigen, dass dies der Fall ist, indem Sie GGCanary.log nach zusätzlichen Fehlern suchen. Wenn die Lambda-Funktion nicht auf das /usr Verzeichnis zugreifen kann, GGCanary.log enthält den folgenden Fehler:

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

Um dieses Problem zu beheben, fügen Sie der Gruppe eine lokale Volume-Ressource hinzu und stellen Sie dann die Gruppe bereit. Diese Ressource muss:

 

Fehler: [FEHLER]-Laufzeitausführungsfehler: Lambda-Container konnte nicht gestartet werden. {"errorString": "failed to initialize container mounts: failed to create overlay fs for container: mounting overlay at /greengrass/ggc/packages/<ggc-version>/rootfs/merged failed: failed to mount with args source=\"no_source\" dest=\"/greengrass/ggc/packages/<ggc-version>/rootfs/merged\" fstype=\"overlay\" flags=\"0\" data=\"lowerdir=/greengrass/ggc/packages/<ggc-version>/dns:/,upperdir=/greengrass/ggc/packages/<ggc-version>/rootfs/upper,workdir=/greengrass/ggc/packages/<ggc-version>/rootfs/work\": too many levels of symbolic links"}

Lösung: Dieser Fehler wird möglicherweise in der runtime.log Datei angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Dieses Problem tritt auf Debian-Betriebssystemen möglicherweise häufiger auf.

Führen Sie folgende Schritte aus, um dieses Problem zu lösen:

 

Fehler: [DEBUG] – Routen konnten nicht abgerufen werden. Nachricht wird verworfen.

Lösung: Überprüfen Sie die Abonnements in Ihrer Gruppe und stellen Sie sicher, dass das in der [DEBUG]-Nachricht aufgelistete Abonnement vorhanden ist.

 

Fehler: [Errno 24] Zu viele geöffnete Dateien <lambda-function> [Errno 24] Zu viele geöffnete Dateien

Lösung: Dieser Fehler wird möglicherweise in Ihrer Lambda-Funktionsprotokolldatei angezeigt, wenn die Funktion StreamManagerClient im Funktionshandler instanziiert. Es wird empfohlen, den Client außerhalb des Handlers zu erstellen. Weitere Informationen finden Sie unter Verwenden von StreamManagerClient um mit Streams zu arbeiten.

 

Fehler: ds-Server konnte Socket nicht abhören: Listen unix <ggc-path>/ggc/socket/greengrass_ipc.sock: Bind: Ungültiges Argument

Lösung: Dieser Fehler wird möglicherweise angezeigt, wenn die AWS IoT Greengrass Core-Software nicht gestartet wird. Dieser Fehler tritt auf, wenn die AWS IoT Greengrass -Core-Software in einem Ordner mit einem langen Dateipfad installiert ist. Installieren Sie die AWS IoT Greengrass Core-Software in einem Ordner mit einem Dateipfad von weniger als 79 Byte, wenn Sie kein Schreibverzeichnis verwenden, oder 83 Byte, wenn Sie ein Schreibverzeichnis verwenden.

[INFO] (Copier) aws.greengrass.StreamManager: stdout. Ursache: com.fasterxml.jackson.databind.JsonMappingException: Instant überschreitet den minimalen oder maximalen Instant

Wenn Sie die AWS IoT Greengrass Kernsoftware auf v1.11.3 aktualisieren, wird möglicherweise der folgende Fehler in den Stream-Manager-Protokollen angezeigt, wenn der Stream-Manager nicht gestartet werden kann.

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}

Wenn Sie eine Version der AWS IoT Greengrass Core-Software vor v1.11.3 verwenden und auf eine neuere Version aktualisieren möchten, verwenden Sie ein OTA-Update, um auf v1.11.4 zu aktualisieren.

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

Wenn Sie apt update auf einem Gerät ausführen, auf dem Sie die AWS IoT Greengrass Core-Software aus einem APT-Repository installiert haben, wird möglicherweise der folgende Fehler angezeigt.

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

Dieser Fehler tritt auf, weil AWS IoT Greengrass nicht mehr die Möglichkeit bietet, die AWS IoT Greengrass Core-Software aus dem APT-Repository zu installieren oder zu aktualisieren. Um erfolgreich auszuführenapt update, entfernen Sie das AWS IoT GreengrassRepository aus der Quellenliste des Geräts.

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

Bereitstellungsprobleme

Im Folgenden finden Sie Informationen zur Behebung von Problemen mit der Bereitstellung.

 

Ihre aktuelle Bereitstellung funktioniert nicht und Sie möchten zu einer früheren, funktionierenden Bereitstellung zurückkehren.

Lösung: Verwenden Sie die AWS IoT Konsole oder AWS IoT Greengrass API, um eine frühere funktionierende Bereitstellung erneut bereitzustellen. Hierdurch wird die entsprechende Gruppenversion auf Ihrem Core-Gerät bereitgestellt.

 

Für die Bereitstellung wird der Fehler „403 Forbidden” in den Protokollen angezeigt.

Lösung: Stellen Sie sicher, dass die Richtlinie des AWS IoT Greengrass Kerns in der Cloud "greengrass:*" als zulässige Aktion enthält.

 

Ein ConcurrentDeployment Fehler tritt auf, wenn Sie den Befehl create-deployment zum ersten Mal ausführen.

Lösung: Möglicherweise wird eine Bereitstellung verarbeitet. Sie können get-deployment-status ausführen, um zu prüfen, ob eine Bereitstellung erstellt wurde. Falls nicht, versuchen Sie erneut, die Bereitstellung zu erstellen.

 

Fehler: Greengrass ist nicht zur Übernahme der Servicerolle berechtigt, die mit diesem Konto verknüpft ist; oder derFehler: Fehlgeschlagen: TES-Servicerolle ist nicht mit diesem Konto verknüpft.

Lösung: Möglicherweise wird Ihnen dieser Fehler angezeigt, wenn die Bereitstellung fehlschlägt. Überprüfen Sie, ob eine Greengrass-Servicerolle mit Ihrem AWS-Konto in der aktuellen verknüpft istAWS-Region. Weitere Informationen finden Sie unter Verwalten der Greengrass-Servicerolle (CLI) oder Verwalten der Greengrass-Servicerolle (Konsole).

 

Fehler: Download-Schritt in der Bereitstellung kann nicht ausgeführt werden. Fehler beim Herunterladen: Fehler beim Herunterladen der Gruppendefinitionsdatei:... x509: Zertifikat ist abgelaufen oder noch nicht gültig

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Wenn eine Deployment failed-Fehlermeldung mit dem Text x509: certificate has expired or is not yet valid angezeigt wird, überprüfen Sie die Uhr des Geräts. TLS- und X.509-Zertifikate bieten eine sichere Grundlage für die Erstellung von IoT-Systemen, erfordern jedoch genaue Zeitangaben auf Servern und Clients. IoT-Geräte sollten die richtige Zeitangabe haben (innerhalb von 15 Minuten), bevor sie versuchen, eine Verbindung zu AWS IoT Greengrass oder anderen TLS-Services herzustellen, die Serverzertifikate verwenden. Weitere Informationen finden Sie unter Verwenden von Gerätezeit zur Validierung von AWS IoT Serverzertifikaten im Internet der Dinge im AWS offiziellen Blog .

 

Die Bereitstellung wird nicht abgeschlossen.

Lösung: Führen Sie die folgenden Schritte aus:

 

Fehler: Java- oder Java8-ausführbare Dateien konnten nicht gefunden werden, oder der Fehler: Bereitstellung <deployment-id> vom Typ NewDeployment für Gruppe <group-id> fehlgeschlagener Fehler: Worker mit <worker-id> konnte nicht initialisiert werden, da die Installierte Java-Version größer oder gleich 8 sein muss

Lösung: Wenn der Stream-Manager für den AWS IoT Greengrass Core aktiviert ist, müssen Sie die Java-8-Laufzeit auf dem Core-Gerät installieren, bevor Sie die Gruppe bereitstellen. Weitere Informationen finden Sie in den Anforderungen für den Stream-Manager. Stream Manager ist standardmäßig aktiviert, wenn Sie den Workflow zur Erstellung von Standardgruppen in der AWS IoTKonsole verwenden, um eine Gruppe zu erstellen.

Oder deaktivieren Sie den Stream-Manager und stellen anschließend die Gruppe bereit. Weitere Informationen finden Sie unter Konfigurieren der Stream-Manager-Einstellungen (Konsole).

 

Die Bereitstellung wird nicht fertiggestellt und „runtime.log“ enthält mehrere Einträge für „1 Sekunde auf Anhalten des Containers gewartet“.

Lösung: Führen Sie folgende Befehle in Ihrem Core-Geräteterminal aus, um den AWS IoT Greengrass-Daemon neu zu starten.

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

 

Die Bereitstellung wird nicht abgeschlossen und runtime.log enthält "[FEHLER]-Greengrass-Bereitstellungsfehler: Fehler beim Melden des Bereitstellungsstatus an die 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"}"

Lösung: Dieser Fehler wird möglicherweise in runtime.log angezeigt, wenn der Greengrass Core für die Verwendung einer HTTPS-Proxyverbindung konfiguriert ist und die Zertifikatskette des Proxy-Servers auf dem System nicht vertrauenswürdig ist. Fügen Sie die Zertifikatkette dem CA-Stammzertifikat hinzu, um dieses Problem zu beheben. Der Greengrass Core fügt die Zertifikate aus dieser Datei dem Zertifikatpool hinzu, der für die TLS-Authentifizierung in HTTPS- und MQTT-Verbindungen mit AWS IoT Greengrass verwendet wird.

Das folgende Beispiel zeigt ein CA-Zertifikat des Proxy-Servers, das der Datei mit dem CA-Stammzertifikat hinzugefügt wurde:

# 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-----

Standardmäßig ist das CA-Stammzertifikat in /greengrass-root/certs/root.ca.pem gespeichert. Wenn Sie den Speicherort auf Ihrem Core-Gerät suchen möchten, überprüfen Sie die Eigenschaft crypto.caPath in der Datei config.json.

 

Fehler: Bereitstellung <deployment-id> vom Typ NewDeployment für Gruppe <group-id> fehlgeschlagen Fehler: Fehler bei der Verarbeitung. Gruppenkonfiguration ist ungültig: 112 oder [119 0] hat keine rw-Berechtigung für die Datei: <path>.

Lösung: Stellen Sie sicher, dass die Besitzergruppe des Verzeichnisses <path> über Lese- und Schreibberechtigungen für das Verzeichnis verfügt.

 

Fehler: <list-of-function-arns> sind für die Ausführung als Root konfiguriert, aber Greengrass ist nicht für die Ausführung von Lambda-Funktionen mit Root-Berechtigungen konfiguriert.

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Stellen Sie sicher, dass Sie so konfiguriert habenAWS IoT Greengrass, dass Lambda-Funktionen mit Root-Berechtigungen ausgeführt werden können. Ändern Sie entweder den Wert von allowFunctionsToRunAsRoot in greengrass_root/config/config.json yes oder ändern Sie die Lambda-Funktion so, dass sie als ein anderer Benutzer/eine andere Gruppe ausgeführt wird. Weitere Informationen finden Sie unter Ausführen einer Lambda-Funktion als Root.

 

Fehler: Bereitstellung <deployment-id> vom Typ NewDeployment für Gruppe <group-id> fehlgeschlagener Fehler: Greengrass-Bereitstellungsfehler: Download-Schritt bei der Bereitstellung nicht ausführen. Fehler während der Verarbeitung: Die heruntergeladene Gruppendatei konnte nicht geladen werden: konnte die UID basierend auf Benutzername nicht finden userName: ggc_user: user: unknown user ggc_user.

Lösung: Wenn die Standardzugriffsidentität der AWS IoT Greengrass Gruppe die Standardsystemkonten verwendet, müssen der ggc_user Benutzer und die ggc_group Gruppe auf dem Gerät vorhanden sein. Anweisungen zum Hinzufügen von Benutzer und Gruppe finden Sie in diesem Schritt. Sie müssen die Namen genau wie gezeigt eingeben.

 

Fehler: [FEHLER]-Laufzeitausführungsfehler: Lambda-Container kann nicht gestartet werden. {"errorString": "Fehler beim Initialisieren von Container-Mounts: Fehler beim Maskieren des Greengrass-Stamms im Overlay-Oberverzeichnis: Fehler beim Erstellen eines Maskengeräts im Verzeichnis <ggc-path>: Datei vorhanden"}

Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Dieser Fehler tritt auf, wenn eine Lambda-Funktion in der Greengrass-Gruppe nicht auf das /usr Verzeichnis im Dateisystem des Kerns zugreifen kann. Um dieses Problem zu beheben, fügen Sie der Gruppe eine lokale Volume-Ressource hinzu und stellen Sie dann die Gruppe bereit. Die Ressource muss:

 

Fehler: Bereitstellung <deployment-id> vom Typ NewDeployment für Gruppe <group-id> fehlgeschlagener Fehler: Prozessstart fehlgeschlagen: container_linux.go:259: Starten des Containerprozesses verursachte „process_linux.go:250: Ausführen des exec setns-Prozesses für init verursachte \"wait: no child processes\"“.

Lösung: Möglicherweise wird Ihnen dieser Fehler angezeigt, wenn die Bereitstellung fehlschlägt. Wiederholen Sie die Bereitstellung.

 

Fehler: [WARN]-MQTT[client] dial tcp: lookup <host-prefix>-ats.iot.<region>.amazonaws.com: kein solcher Host ... [ERROR]-Greengrass-Bereitstellungsfehler: Bereitstellungsstatus konnte nicht zurück an die Cloud gemeldet werden ... net/http: Anforderung abgebrochen, während auf Verbindung gewartet wurde (Client.Timeout überschritten, während Header gewartet wurden)

Lösung: Dieser Fehler wird Ihnen möglicherweise angezeigt, wenn Sie systemd-resolved verwenden. Hierdurch wird die Einstellung DNSSEC standardmäßig aktiviert. Daher werden zahlreiche öffentliche Domänen nicht erkannt. Verbindungsversuche mit dem AWS IoT Greengrass-Endpunkt können den Host nicht finden, sodass Ihre Bereitstellungen weiter den Status In Progress haben.

Sie können die folgenden Befehle und Ausgaben verwenden, um auf dieses Problem zu testen. Ersetzen Sie den Platzhalter für die Region in den Endpunkten durch Ihr AWS-Region.

$ 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

Eine mögliche Lösung besteht darin, DNSSEC zu deaktivieren. Wenn DNSSEC false ist, werden DNS-Lookups nicht DNSSEC-validiert. Weitere Informationen finden Sie unter diesem bekannten Problem für systemd.

Um Informationen zu resolved.conf und DNSSEC zu erhalten, führen Sie man resolved.conf in Ihrem Terminal aus.

 

Probleme beim Erstellen der Gruppe oder Funktion

Verwenden Sie die folgenden Informationen, um Probleme beim Erstellen einer -AWS IoT GreengrassGruppe oder Greengrass-Lambda-Funktion zu beheben.

 

Fehler: Ihre IsolationMode'-Konfiguration für die Gruppe ist ungültig.

Lösung: Dieser Fehler tritt auf, wenn der Wert IsolationMode in der DefaultConfig von function-definition-version nicht unterstützt wird. Unterstützte Werte sind GreengrassContainer und NoContainer.

 

Fehler: Ihre 'IsolationMode-Konfiguration für die Funktion mit arn <function-arn> ist ungültig.

Lösung: Dieser Fehler tritt auf, wenn der Wert IsolationMode in <function-arn> der function-definition-version nicht unterstützt wird. Unterstützte Werte sind GreengrassContainer und NoContainer.

 

Fehler: MemorySize Die Konfiguration für die Funktion mit arn <function-arn> ist in IsolationMode= nicht zulässigNoContainer.

Lösung: Dieser Fehler tritt auf, wenn Sie einen MemorySize Wert angeben und ohne Containerisierung ausführen möchten. Lambda-Funktionen, die ohne Containerisierung ausgeführt werden, können keine Speicherlimits haben. Sie können das Limit entweder entfernen oder die Lambda-Funktion so ändern, dass sie in einem -AWS IoT GreengrassContainer ausgeführt wird.

 

Fehler: Zugriff auf die Sysfs-Konfiguration für Funktion mit arn <function-arn> ist in IsolationMode= nicht zulässigNoContainer.

Lösung: Dieser Fehler tritt auf, wenn Sie true für angeben AccessSysfs und ohne Containerisierung ausführen möchten. Lambda-Funktionen, die ohne Containerisierung ausgeführt werden, müssen ihren Code aktualisiert haben, um direkt auf das Dateisystem zuzugreifen, und können nicht verwendenAccessSysfs. Sie können entweder den Wert false für angeben AccessSysfs oder die Lambda-Funktion so ändern, dass sie in einem -AWS IoT GreengrassContainer ausgeführt wird.

 

Fehler: MemorySize Konfiguration für Funktion mit arn <function-arn> ist in IsolationMode= erforderlichGreengrassContainer.

Lösung: Dieser Fehler tritt auf, weil Sie kein MemorySize Limit für eine Lambda-Funktion angegeben haben, die Sie in einem -AWS IoT GreengrassContainer ausführen. Geben Sie einen MemorySize-Wert an, um den Fehler zu beheben.

 

Fehler: Funktion <function-arn> bezieht sich auf eine Ressource vom Typ <resource-type>, die in IsolationMode= nicht zulässig istNoContainer.

Lösung: Sie können nicht auf die S3_Object.Generic_Archive Ressourcentypen Local.Device, Local.Volume, ML_Model.SageMaker.Job, oder zugreifenML_Model.S3_Object, wenn Sie eine Lambda-Funktion ohne Containerisierung ausführen. Wenn Sie diese Ressourcentypen benötigen, müssen Sie die Funktion in einem AWS IoT Greengrass-Container ausführen. Sie können auch direkt auf lokale Geräte zugreifen, wenn Sie ohne Containerisierung ausführen, indem Sie den Code in Ihrer Lambda-Funktion ändern.

 

Fehler: Die Ausführungskonfiguration für die Funktion mit dem ARN <function-arn> ist nicht zulässig.

Lösung: Dieser Fehler tritt auf, wenn Sie eine System-Lambda-Funktion mit GGIPDetector oder erstellen GGCloudSpooler und die - IsolationMode oder -RunAsKonfiguration angegeben haben. Sie müssen die Execution Parameter für diese System-Lambda-Funktion weglassen.

 

Erkennungsprobleme

Verwenden Sie die folgenden Informationen zur Behandlung von Problemen mit den AWS IoT Greengrass-Konnektoren.

 

Fehler: Gerät gehört zu vielen Gruppen an; Geräte dürfen nicht mehr als 10 Gruppen angehören

Lösung: Dies ist eine bekannte Einschränkung. Ein Client-Gerät kann Mitglied von bis zu 10 Gruppen sein.

 

Probleme mit Machine Learning-Ressourcen

Verwenden Sie die folgenden Informationen, um Probleme mit Machine Learning-Ressourcen zu beheben.

 

InvalidMLModelOwner GroupOwnerSetting –wird in der ML-Modellressource bereitgestellt, aber GroupOwner oder GroupPermission ist nicht vorhanden

Lösung: Sie erhalten diesen Fehler, wenn eine Machine-Learning-Ressource das ResourceDownloadOwnerSetting Objekt enthält, die erforderliche - GroupOwner oder -GroupPermissionEigenschaft jedoch nicht definiert ist. Um dieses Problem zu beheben, definieren Sie die fehlende Eigenschaft.

 

NoContainer Die -Funktion kann die Berechtigung nicht konfigurieren, wenn Machine Learning-Ressourcen angefügt werden. <function-arn> bezieht sich auf die Machine-Learning-Ressource <resource-id> mit der Berechtigung <ro/rw> in der Ressourcenzugriffsrichtlinie.

Lösung: Sie erhalten diesen Fehler, wenn eine nicht containerisierte Lambda-Funktion Berechtigungen auf Funktionsebene für eine Machine-Learning-Ressource angibt. Nicht containerisierte Funktionen müssen Berechtigungen von den Ressourcenbesitzer-Berechtigungen erben, die für die Machine Learning-Ressource definiert sind. Um dieses Problem zu beheben, wählen Sie , um Berechtigungen des Ressourcenbesitzers zu erben (Konsole) oder entfernen Sie die Berechtigungen aus der Ressourcenzugriffsrichtlinie (API) der Lambda-Funktion.

 

Funktion <function-arn> bezieht sich auf die Machine Learning-Ressource <resource-id> mit fehlender Berechtigung sowohl in als auch in der ResourceAccessPolicy Ressource OwnerSetting.

Lösung: Sie erhalten diesen Fehler, wenn Berechtigungen für die Machine-Learning-Ressource nicht für die angehängte Lambda-Funktion oder die Ressource konfiguriert sind. Um dieses Problem zu beheben, konfigurieren Sie Berechtigungen in der -ResourceAccessPolicyEigenschaft für die Lambda-Funktion oder der -OwnerSettingEigenschaft für die -Ressource.

 

Funktion <function-arn> bezieht sich auf die Machine Learning-Ressource <resource-id> mit der Berechtigung \"rw\", während die Einstellung GroupPermission des Ressourcenbesitzers nur \"ro\" zulässt.

Lösung: Sie erhalten diesen Fehler, wenn die für die angefügte Lambda-Funktion definierten Zugriffsberechtigungen die für die Machine-Learning-Ressource definierten Berechtigungen des Ressourcenbesitzers überschreiten. Um dieses Problem zu beheben, legen Sie restriktivere Berechtigungen für die Lambda-Funktion oder weniger restriktive Berechtigungen für den Ressourcenbesitzer fest.

 

NoContainer Funktion <function-arn> bezieht sich auf Ressourcen des verschachtelten Zielpfads.

Lösung: Sie erhalten diesen Fehler, wenn mehrere Machine-Learning-Ressourcen, die einer nicht containerisierten Lambda-Funktion zugeordnet sind, denselben Zielpfad oder einen verschachtelten Zielpfad verwenden. Um dieses Problem zu beheben, geben Sie separate Zielpfade für die Ressourcen an.

 

Lambda <function-arn> erhält Zugriff auf die Ressource <resource-id>, indem dieselbe Gruppenbesitzer-ID freigegeben wird

Lösung: Sie erhalten diesen Fehler in , runtime.log wenn dieselbe Betriebssystemgruppe als „Als Identität ausführen“ der Lambda-Funktion und als Ressourcenbesitzer für eine Machine-Learning-Ressource angegeben ist, die Ressource jedoch nicht an die Lambda-Funktion angehängt ist. Diese Konfiguration erteilt der Lambda-Funktion implizite Berechtigungen, mit denen sie ohne AWS IoT Greengrass Autorisierung auf die Ressource zugreifen kann.

Um dieses Problem zu beheben, verwenden Sie eine andere Betriebssystemgruppe für eine der Eigenschaften oder fügen Sie die Machine-Learning-Ressource an die Lambda-Funktion an.

AWS IoT Greengrass Core-Probleme in Docker

Verwenden Sie die folgenden Informationen, um Probleme beim Ausführen eines AWS IoT Greengrass-Cores in einem Docker-Container zu beheben.

 

Fehler: Unbekannte Optionen: -no-include-email.

Lösung: Dieser Fehler kann auftreten, wenn Sie den Befehl aws ecr get-login ausführen. Stellen Sie sicher, dass die neueste AWS CLI-Version (z. B. run: pip install awscli --upgrade --user) installiert ist. Wenn Sie Windows verwenden und die CLI mit dem MSI-Installationsprogramm installiert haben, müssen Sie den Installationsvorgang wiederholen. Weitere Informationen finden Sie unter Installieren der AWS Command Line Interface unter Microsoft Windows im AWS Command Line Interface -Benutzerhandbuch.

 

Warnung: IPv4 ist deaktiviert. Das Netzwerk wird nicht funktionieren.

Lösung: Sie können diese Warnung oder eine ähnliche Nachricht erhalten, wenn Sie AWS IoT Greengrass auf einem Linux-Computer ausführen. Aktivieren Sie die IPv4-Netzwerkweiterleitung wie in diesem Schritt beschrieben. Die AWS IoT Greengrass-Cloud Bereitstellung und MQTT-Kommunikation sind nicht funktionsfähig, wenn die IPv4-Weiterleitung nicht aktiviert ist. Weitere Informationen finden Sie unter Configure namespaced kernel parameters (sysctls) at runtime in der Docker-Dokumentation.

 

Fehler: Eine Firewall blockiert die Freigabe von Dateien zwischen Fenstern und den Containern.

Lösung: Sie können diese Fehlermeldung oder eine Firewall Detected-Nachricht erhalten, wenn Sie Docker auf einem Windows-Computer ausführen. Dies kann auch auftreten, wenn Sie an einem Virtual Private Network (VPN) angemeldet sind und Ihre Netzwerkeinstellungen die Bereitstellung des freigegebenen Laufwerks verhindern. Deaktivieren Sie in diesem Fall das VPN und führen Sie den Docker-Container erneut aus.

 

Fehler: Beim Aufrufen der - GetAuthorizationToken Operation ist ein Fehler (AccessDeniedException) aufgetreten: Benutzer: arn:aws:iam::<account-id>:user/<user-name> ist nicht berechtigt: ecr:GetAuthorizationToken on Ressource: *

Dieser Fehler wird möglicherweise angezeigt, wenn Sie den aws ecr get-login-password Befehl ausführen, wenn Sie nicht über ausreichende Berechtigungen für den Zugriff auf ein Amazon-ECR-Repository verfügen. Weitere Informationen finden Sie unter Beispiele für Amazon-ECR-Repository-Richtlinien und Zugriff auf ein Amazon-ECR-Repository im Amazon-ECR-Benutzerhandbuch.

 

Fehler: Container kann für den Greengrass-Service nicht erstellt werden: Konflikt. Der Containername „/aws-iot-greengrass“ wird bereits verwendet.

Lösung: Dies kann auftreten, wenn der Containername von einem älteren Container verwendet wird. Um dieses Problem zu beheben, führen Sie den folgenden Befehl aus, um den alten Docker-Container zu entfernen:

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

 

Fehler: [FATAL] -Fehler beim Zurücksetzen des Mount-Namespace des Threads aufgrund eines unerwarteten Fehlers: „Vorgang nicht zulässig“. Zur Sicherstellung der Konsistenz wird GGC abstürzen und manuell neu gestartet werden.

Lösung: Dieser Fehler in runtime.log kann auftreten, wenn Sie versuchen, eine GreengrassContainer Lambda-Funktion auf einem AWS IoT Greengrass-Core bereitzustellen, der in einem Docker-Container ausgeführt wird. Derzeit können nur NoContainer Lambda-Funktionen in einem Greengrass-Docker-Container bereitgestellt werden.

Um dieses Problem zu beheben, stellen Sie sicher, dass sich alle Lambda-Funktionen im -NoContainerModus befinden, und starten Sie eine neue Bereitstellung. Wenn Sie dann den Container starten, dürfen Sie das vorhandene deployment Verzeichnis nicht auf dem Docker-AWS IoT GreengrassCore-Container binden. Erstellen Sie stattdessen ein leeres deployment-Verzeichnis an seiner Stelle und fügen Sie es über Bind-Mount im Docker-Container ein. Auf diese Weise kann der neue Docker-Container die neueste Bereitstellung mit Lambda-Funktionen empfangen, die im -NoContainerModus ausgeführt werden.

Weitere Informationen finden Sie unter Ausführen von AWS IoT Greengrass in einem Docker-Container.

Fehlerbehebung mit Protokollen

Sie können Protokollierungseinstellungen für eine Greengrass-Gruppe konfigurieren, z. B. ob Protokolle an CloudWatch Protokolle gesendet, Protokolle auf dem lokalen Dateisystem gespeichert oder beides. Wenn Sie detaillierte Informationen zur Problembehandlung erhalten möchten, können Sie die Protokollierungsstufe vorübergehend zu DEBUG ändern. Änderungen an den Protokollierungseinstellungen werden wirksam, wenn Sie die Gruppe bereitstellen. Weitere Informationen finden Sie unter Konfigurieren der Protokollierung für AWS IoT Greengrass.

Auf dem lokalen Dateisystem speichert AWS IoT Greengrass Protokolle an den folgenden Speicherorten. Das Lesen der Protokolle auf dem Dateisystem erfordert Root-Berechtigungen.

Wenn die Protokolle so konfiguriert sind, dass sie in der Cloud gespeichert werden, verwenden Sie CloudWatch -Protokolle, um Protokollmeldungen anzuzeigen. crash.log befindet sich nur in Dateisystemprotokollen auf dem AWS IoT Greengrass Core-Gerät.

Wenn so konfiguriert AWS IoT ist, dass Protokolle in geschrieben werden CloudWatch, überprüfen Sie diese Protokolle, wenn Verbindungsfehler auftreten, wenn Systemkomponenten versuchen, eine Verbindung zu herzustellenAWS IoT.

Weitere Informationen zur AWS IoT Greengrass-Protokollierung finden Sie unter Überwachen mit AWS IoT Greengrass-Protokollen.

Fehlerbehebung bei Speicherproblemen

Wenn der lokale Dateispeicher voll ist, schlagen einige Komponenten möglicherweise fehl:

Sie sollten immer wissen, wie viel lokaler Speicherplatz verfügbar ist. Sie können freien Speicherplatz basierend auf der Größe der bereitgestellten Lambda-Funktionen, der Protokollierungskonfiguration (siehe Fehlerbehebung mit Protokollen) und der Anzahl der lokal gespeicherten Schatten berechnen.

Fehlerbehebung für Nachrichten

Alle lokal gesendeten Nachrichten in AWS IoT Greengrass werden mit QoS 0 gesendet. Standardmäßig speichert AWS IoT Greengrass Nachrichten in einer speicherinternen Warteschlange. Daher gehen nicht verarbeitete Nachrichten verloren, wenn der Greengrass-Core neu gestartet wird (z. B. nach einer Gruppenbereitstellung oder einem Geräteneustart). Sie können jedoch AWS IoT Greengrass (v1.6 oder höher) so konfigurieren, dass Nachrichten im Dateisystem zwischengespeichert werden, sodass sie über Kernneustarts hinweg bestehen bleiben. Sie können auch die Größe der Warteschlange konfigurieren. Falls Sie eine Warteschlangengröße konfigurieren, stellen Sie sicher, dass sie größer als oder gleich 262144 Byte (256 KB) ist. Andernfalls wird AWS IoT Greengrass möglicherweise nicht ordnungsgemäß gestartet. Weitere Informationen finden Sie unter MQTT-Nachrichtenwarteschlange für Cloud-Ziele.

Sie können den Core auch so konfigurieren, dass persistente Sitzungen mit AWS IoT eingerichtet werden. Auf diese Weise kann der Kern Nachrichten empfangen, die vom gesendet werden, AWS Cloud während der Kern offline ist. Weitere Informationen finden Sie unter Persistente MQTT-Sitzungen mit AWS IoT Core.

Beheben von Timeout-Problemen während der Schattensynchronisierung

Erhebliche Verzögerungen bei der Kommunikation zwischen einem Greengrass Core-Gerät und der Cloud können dazu führen, dass die Schattensynchronisierung wegen einer Zeitüberschreitung fehlschlägt. In diesem Fall sollten Protokolleinträge angezeigt werden, die etwa wie folgt aussehen:

[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 []}"

Eine mögliche Lösung besteht darin, die Zeitspanne festzulegen, die das Core-Gerät auf eine Antwort des Hosts wartet. Öffnen Sie die Datei config.json in greengrass-root/config, und fügen Sie ein system.shadowSyncTimeout-Feld mit einem Zeitüberschreitungswert in Sekunden hinzu. Beispielsweise:

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

Wenn in config.json kein shadowSyncTimeout-Wert angegeben ist, lautet der Standardwert 5 Sekunden.

AWS re:Post prüfen

Wenn Sie Ihr Problem nicht mithilfe der Informationen zur Fehlerbehebung in diesem Thema beheben können, können Sie das AWS IoT Greengrass-Tag auf AWS re:Post nach verwandten Problemen durchsuchen Fehlerbehebung für AWS IoT Greengrass oder eine neue Frage stellen. Mitglieder des AWS IoT Greengrass Teams überwachen AWS re:Post aktiv.