Hinweis zum Ende des Supports: Am 7. Oktober 2026 AWS wird der Support für eingestellt. AWS IoT Greengrass Version 1 Nach dem 7. Oktober 2026 werden Sie nicht mehr auf die Ressourcen zugreifen können. AWS IoT Greengrass V1 Weitere Informationen finden Sie unter Migrieren von AWS IoT Greengrass Version 1.
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 AWS IoT Greengrass
Dieser Abschnitt enthält Informationen zur Problembehandlung und mögliche Lösungen zur Behebung von Problemen mit AWS IoT Greengrass.
Informationen zu AWS IoT Greengrass Kontingenten (Grenzwerten) finden Sie unter Servicekontingente im Allgemeine Amazon Web Services-Referenz.
AWS IoT Greengrass Kernfragen
Wenn die AWS IoT Greengrass Core-Software nicht startet, versuchen Sie die folgenden allgemeinen Schritte zur Problembehandlung:
-
Stellen Sie sicher, dass Sie die Binärdateien installieren, die für Ihre Architektur geeignet sind. Weitere Informationen finden Sie unter AWS IoT Greengrass Core-Software.
-
Stellen Sie sicher, dass Ihr Core-Gerät über lokalen Speicherplatz verfügt. Weitere Informationen finden Sie unter Fehlerbehebung bei Speicherproblemen.
-
Überprüfen Sie
runtime.logundcrash.logauf Fehlermeldungen. Weitere Informationen finden Sie unter Fehlerbehebung mit Protokollen.
Suchen Sie nach den folgenden Symptomen und Fehlern, um Informationen zur Behebung von Problemen mit einem AWS IoT Greengrass Core zu finden.
Problembereiche
Fehler: < > /greengrass-root/.json konnte nicht analysiert werden. config/config
Fehler: Beim Generieren der TLS-Konfiguration ist ein Fehler aufgetreten: ErrUnknownURIScheme
Fehler: Spulengröße sollte mindestens 262144 Bytes betragen.
Fehler: [DEBUG] – Routen konnten nicht abgerufen werden. Nachricht wird verworfen.
Fehler: [Errno 24] Zu viele geöffnete < Lambda-Funktionen>, [Errno 24] Zu viele geöffnete Dateien
Fehler: In der Konfigurationsdatei fehlt das CaPath, CertPath oder KeyPath. Der Greengrass-Daemon-Prozess mit [pid = < pid>] ist gestorben.
Lösung: Möglicherweise wird dieser Fehler angezeigt, crash.log 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:
-
Führen Sie ein Upgrade auf Version 1.7 oder höher durch. Wir empfehlen, dass Sie immer die neueste Version der AWS IoT Greengrass Core-Software ausführen. Informationen zum Download finden Sie unter AWS IoT Greengrass Core-Software.
-
Verwenden Sie das richtige
config.jsonFormat für Ihre AWS IoT Greengrass Core-Softwareversion. Weitere Informationen finden Sie unter AWS IoT Greengrass Kernkonfigurationsdatei.Anmerkung
Um herauszufinden, welche Version der AWS IoT Greengrass Core-Software auf dem Core-Gerät installiert ist, führen Sie die folgenden Befehle in Ihrem Geräteterminal aus.
cd /greengrass-root/ggc/core/ sudo ./greengrassd --version
Fehler: < > /greengrass-root/.json konnte nicht analysiert werden. config/config
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 /) und validieren Sie das JSON-Format. Stellen Sie z. B. sicher, dass Kommas korrekt verwendet werden.greengrass-root/config
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 /) und überprüfen Sie den Abschnitt greengrass-root/configcrypto. 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 /). Fügen Sie im Objekt greengrass-root/configruntime 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. Beispiel:
... "runtime" : { "cgroup" : { "useSystemd" : "yes" }, "postStartHealthCheckTimeout" : 40000 }, ...
Fehler: Fehler beim Aufrufen PutLogEvents auf der lokalen Cloudwatch, LogGroup:/GreengrassSystem/connection_manager, Fehler: RequestError Die Sendeanfrage ist fehlgeschlagen, verursacht durch: Post http://<path>/cloudwatch/logs/: < TCP-Adresse wählen: 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 auftreten, wenn Sie AWS IoT Greengrass auf einem Raspberry Pi arbeiten und die erforderliche Speichereinrichtung noch nicht abgeschlossen wurde. Weitere Informationen finden Sie in diesem Schritt.
Fehler: Der Server konnte nicht erstellt werden aufgrund: Gruppe konnte nicht geladen werden: chmod/<greengrass-root/ggc/deployment/:aws:lambda: region: > account-id:function<: function-namelambda/arn: version>/file-name<: keine solche Datei oder kein solches Verzeichnis. > < > < > < >
Lösung: Möglicherweise wird Ihnen diese Fehlermeldung angezeigt, wenn die AWS IoT Greengrass
Core-Software nicht gestartet wird. Wenn Sie eine ausführbare Lambda-Datei im Core bereitgestellt haben, überprüfen Sie die Eigenschaft der Funktion in der Datei (sie befindet sich in///group). Handler group.json greengrass-root ggc/deployment 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).
Das Tool AWS IoT Greengrass Die Kernsoftware startet nicht, nachdem Sie von der Ausführung ohne Containerisierung zur Ausführung in einem Greengrass-Container gewechselt haben.
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 /), ersetzen Sie den Inhalt der Datei mit einem leeren JSON-Objekt (greengrass-root/ggc/deployment/group{}) 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. AWS IoT Greengrass Kernkonfigurationsdatei Wenn die Eigenschaft nicht vorhanden ist, fügen Sie sie dem coreThing-Objekt hinzu. Beispiel:
{ "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: Das Starten des Container-Prozesses verursachte „process_linux.go:424: container-init caused\“ Permission denied\\\ "\"“. 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:
Lösung: Dieser Fehler tritt möglicherweise auf, wenn die Core-Software nicht gestartet wird. runtime.log AWS IoT Greengrass 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 läuft mit PID: < 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 er AWS IoT Greengrass über Berechtigungen iot:UpdateThingShadow und iot:GetThingShadow Aktionen in der Greengrass-Servicerolle verfügt. Greengrass-Servicerolle 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 dann die AWS IoT Greengrass Core-Software neu.
ulimit -n 2048
Anmerkung
In diesem Beispiel wird das Limit auf 2048 erhöht. Wählen Sie einen für Ihren Anwendungsfall geeigneten Wert.
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 entweder AWS IoT Greengrass direkt im Stammverzeichnis, oder stellen Sie sicher, dass das Verzeichnis, in dem die AWS IoT Greengrass Core-Software installiert ist, und die übergeordneten Verzeichnisse über execute Berechtigungen für alle Benutzer verfügen.
Warnung: [WARN] - [5] GK Remote: Fehler beim Abrufen der öffentlichen Schlüsseldaten: ErrPrincipalNotConfigured: Der private Schlüssel für MqttCertificate ist nicht gesetzt.
Lösung: AWS IoT Greengrass verwendet einen gemeinsamen Handler, um die Eigenschaften aller Sicherheitsprinzipale zu überprüfen. 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 Die wichtigsten Sicherheitsprinzipien.
Fehler: Beim Versuch, die Rolle für den Zugriff auf die s3-URL arn:aws:iam::<account-id>:role/<role-name> https://<region>-greengrass-updates.s3.<region>.amazonaws.com/core/<architecture>/greengrass-core-<distribution-version>.tar.gz zu verwenden, wurde die Berechtigung verweigert.
Lösung: Möglicherweise wird Ihnen dieser Fehler angezeigt, wenn eine Over-the-Air (OTA)-Aktualisierung fehlschlägt. Fügen Sie in der Rollenrichtlinie für Unterzeichner das Ziel AWS-Region als Resource hinzu. Diese Unterzeichnerrolle wird verwendet, um die S3-URL für das Softwareupdate vorab zu signieren. AWS IoT Greengrass Weitere Informationen finden Sie unter S3-URL-Signer-Rolle.
Das Tool AWS IoT Greengrass Core ist für die Verwendung von konfiguriert Netzwerk-Proxy 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 Herstellen von Verbindungen verwendet werden, erhalten Sie möglicherweise auch Verbindungs-Timeout-Fehler. Stellen Sie sicher, dass Ihre Lambda-Funktionen die entsprechende Proxykonfiguration verwenden, um eine Verbindung über den Netzwerk-Proxy herzustellen. AWS IoT Greengrass übergibt die Proxykonfiguration über die Umgebungsvariablenhttp_proxy, https_proxy und no_proxy an benutzerdefinierte Lambda-Funktionen. 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). AWS IoT Greengrass Unterstützt für diese Variablen beide.
Anmerkung
Die meisten gängigen Bibliotheken, die verwendet werden, um Verbindungen (z. B. boto3 oder cURL und Python-requests-Pakete) herzustellen, verwenden diese Umgebungsvariablen standardmäßig.
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 sind identisch 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.
So überschreiben Sie die standardmäßige Client-ID für das Core-Gerät
-
Führen Sie den folgenden Befehl aus, um den Greengrass-Daemon zu stoppen:
cd /greengrass-root/ggc/core/ sudo ./greengrassd stop -
Öffnen Sie
zur Bearbeitung als su-Benutzer.greengrass-root/config/config.json -
Fügen Sie im
coreThing-Objekt diecoreClientId-Eigenschaft hinzu und legen Sie für den Wert Ihre benutzerdefinierte Client-ID fest. Der Wert muss zwischen 1 und 128 Zeichen enthalten. Er muss in der aktuellen Version AWS-Region für den eindeutig sein. AWS-Konto"coreClientId": "MyCustomClientId" -
Starten Sie den -Daemon.
cd /greengrass-root/ggc/core/ sudo ./greengrassd start
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 tritt dieser Fehler möglicherweise auf, runtime.log wenn AWS IoT Greengrass versucht wird, 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:
-
Aktivieren Sie die Option
CONFIG_DEVPTS_MULTIPLE_INSTANCESim Linux-Kernel. -
Legen Sie die
/proc-Mountingoptionen auf dem Host nur aufrw,relatimfest. -
Aktualisieren Sie den Linux-Kernel auf 4.9 oder höher.
Anmerkung
Dieses Problem steht nicht im Zusammenhang mit dem Mounten von /proc für den lokalen Ressourcenzugriff.
[FEHLER] — Laufzeitfehler: Der Lambda-Container kann nicht gestartet werden. {"errorString“: „Container-Mounts konnten nicht initialisiert werden: Greengrass-Root konnte nicht im oberen Verzeichnis des Overlays maskiert werden: Fehler beim Erstellen des Maskengeräts im Verzeichnis ggc-Path: Datei existiert"} < >
Lösung: Möglicherweise wird dieser Fehler 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 Cores 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:
-
/usrals Quellpfad und Zielpfad angeben -
Automatisch Betriebssystem-Gruppenberechtigungen der Linux-Gruppe hinzufügen, zu der die Ressource gehört
-
Sie müssen der Lambda-Funktion zugeordnet sein und nur Lesezugriff gewähren.
[FEHLER] — Die Bereitstellung ist fehlgeschlagen. {"deploymentId“: "<deployment-id > „, „errorString“: „Container-Testvorgang mit < PID > fehlgeschlagen: Container-Prozessstatus: Exit-Status 1"}
Lösung: Möglicherweise wird dieser Fehler 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 Cores zugreifen kann.
Sie können bestätigen, dass dies der Fall ist, indem Sie nach weiteren Fehlern GGCanary.log suchen. Wenn die Lambda-Funktion nicht auf das /usr Verzeichnis zugreifen kann, GGCanary.log wird der folgende Fehler angezeigt:
[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:
-
/usrals Quellpfad und Zielpfad angeben -
Automatisch Betriebssystem-Gruppenberechtigungen der Linux-Gruppe hinzufügen, zu der die Ressource gehört
-
Sie müssen der Lambda-Funktion zugeordnet sein und nur Lesezugriff gewähren.
Fehler: [ERROR] — Laufzeitfehler: Der Lambda-Container kann nicht gestartet werden. {"errorString“: „Container-Mounts konnten nicht initialisiert werden: Overlay-FS für Container konnte nicht erstellt werden: Overlay unter/greengrass/ggc/packages/ < ggc-version/rootfs/merged konnte nicht gemountet werden: Fehler beim Mounten mit args source=\" no_source\“ dest=\“>/greengrass/ggc/packages/ ggc-version/\“ fstype=\ "overlay\“ flags=\ "0rootfs/merged\“ data=\ ">lowerdir=/ /Pakete/ < ggc-version /dns:/, upperdir=/ /Pakete/ ggc-version/, greengrass/ggc workdir=/ /Pakete/ ggc-version < > greengrass/ggc < > rootfs/upper greengrass/ggc < >/rootfs/work\“: zu viele Ebenen symbolischer Links "}
Lösung: Möglicherweise wird dieser Fehler 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:
-
Aktualisieren Sie die AWS IoT Greengrass Core-Software auf Version 1.9.3 oder höher. Dadurch sollte dieses Problem automatisch behoben werden.
-
Wenn dieser Fehler nach dem Upgrade der AWS IoT Greengrass Core-Software immer noch auftritt, legen Sie die
system.useOverlayWithTmpfsEigenschafttruein der Datei config.json auf fest.Beispiel Beispiel
{ "system": { "useOverlayWithTmpfs": true }, "coreThing": { "caPath": "root-ca.pem", "certPath": "cloud.pem.crt", "keyPath": "cloud.pem.key", ... }, ... }
Anmerkung
Ihre AWS IoT Greengrass Core-Softwareversion wird in der Fehlermeldung angezeigt. Führen Sie uname -r aus, um Ihre Linux-Kernel-Version zu suchen.
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 < Lambda-Funktionen>, [Errno 24] Zu viele geöffnete Dateien
Lösung: Möglicherweise wird dieser Fehler in Ihrer Lambda-Funktionsprotokolldatei angezeigt, wenn die Funktion im Funktionshandler instanziiert wird. StreamManagerClient Es wird empfohlen, den Client außerhalb des Handlers zu erstellen. Weitere Informationen finden Sie unter Wird verwendet StreamManagerClient , um mit Streams zu arbeiten.
Fehler: Der DS-Server konnte nicht mit dem Abhören von Socket beginnen: listen unix < ggc-path>/ggc/socket/greengrass_ipc.sock: bind: ungültiges Argument
Lösung: Möglicherweise wird dieser Fehler angezeigt, wenn die Core-Software nicht gestartet wird. AWS IoT Greengrass Dieser Fehler tritt auf, wenn die AWS IoT Greengrass Core-Software in einem Ordner mit einem langen Dateipfad installiert wird. Installieren Sie die AWS IoT Greengrass Core-Software erneut in einem Ordner mit einem Dateipfad, der weniger als 79 Byte enthält, wenn Sie kein Schreibverzeichnis verwenden, oder 83 Byte, wenn Sie ein Schreibverzeichnis verwenden.
[INFO] (Kopierer) aws.greengrass. StreamManager: robust. Verursacht durch: com.fasterxml.jackson.databind. JsonMappingException: Instant überschreitet den minimalen oder maximalen Instant-Wert
Wenn Sie die AWS IoT Greengrass Kernsoftware auf Version 1.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 du eine ältere Version der AWS IoT Greengrass Kernsoftware als v1.11.3 verwendest und ein Upgrade auf eine neuere Version durchführen möchtest, verwende ein OTA-Update, um auf v1.11.4 zu aktualisieren.
GPG-Fehler: https://dnw9lb6lzp2d8.cloudfront.net stabil: Die folgenden Signaturen waren ungültig InRelease: EXPKEYSIG 68D644ABD2327D47 AWS Greengrass Master Key
Wenn Sie apt update auf einem Gerät ausführen, auf dem Sie die AWS IoT Greengrass Kernsoftware 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 AWS IoT Greengrass auf, weil die Option, die AWS IoT Greengrass Kernsoftware aus dem APT-Repository zu installieren oder zu aktualisieren, nicht mehr angeboten wird. Um erfolgreich zu startenapt
update, entfernen Sie das AWS IoT Greengrass Repository 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.
So stellen Sie eine Bereitstellung erneut bereit (Konsole)
-
Wählen Sie auf der Seite mit der Gruppenkonfiguration den Tab Deployments aus. Diese Seite zeigt den Bereitstellungsverlauf für die Gruppe an, einschließlich Datum und Uhrzeit, Gruppenversion und Status der einzelnen Bereitstellungsversuche.
-
Suchen Sie die Zeile mit der Bereitstellung, die Sie erneut bereitstellen möchten. Wählen Sie die Bereitstellung aus, die Sie erneut bereitstellen möchten, und klicken Sie auf Erneut bereitstellen.
So stellen Sie eine Bereitstellung erneut bereit (CLI)
-
Verwenden Sie diese Option ListDeployments, um die ID der Bereitstellung zu ermitteln, die Sie erneut bereitstellen möchten. Beispiel:
aws greengrass list-deployments --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7Der Befehl gibt die Liste der Bereitstellungen für die Gruppe zurück.
{ "Deployments": [ { "DeploymentId": "8d179428-f617-4a77-8a0c-3d61fb8446a6", "DeploymentType": "NewDeployment", "GroupArn": "arn:aws:greengrass:us-west-2:123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/8dd1d899-4ac9-4f5d-afe4-22de086efc62", "CreatedAt": "2019-07-01T20:56:49.641Z" }, { "DeploymentId": "f8e4c455-8ac4-453a-8252-512dc3e9c596", "DeploymentType": "NewDeployment", "GroupArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/4ad66e5d-3808-446b-940a-b1a788898382", "CreatedAt": "2019-07-01T20:41:47.048Z" }, { "DeploymentId": "e4aca044-bbd8-41b4-b697-930ca7c40f3e", "DeploymentType": "NewDeployment", "GroupArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/versions/1f3870b6-850e-4c97-8018-c872e17b235b", "CreatedAt": "2019-06-18T15:16:02.965Z" } ] }Anmerkung
Diese AWS CLI Befehle verwenden Beispielwerte für die Gruppen- und Bereitstellungs-ID. Wenn Sie die Befehle ausführen, müssen Sie die Beispielwerte ersetzen.
-
Wird verwendet CreateDeployment, um die Zielbereitstellung erneut bereitzustellen. Legen Sie den Bereitstellungstyp auf
Redeploymentfest. Beispiel:aws greengrass create-deployment --deployment-type Redeployment \ --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7 \ --deployment-id f8e4c455-8ac4-453a-8252-512dc3e9c596Der Befehl gibt den ARN und die ID der neuen Bereitstellung zurück.
{ "DeploymentId": "f9ed02b7-c28e-4df6-83b1-e9553ddd0fc2", "DeploymentArn": "arn:aws:greengrass:us-west-2::123456789012:/greengrass/groups/74d0b623-c2f2-4cad-9acc-ef92f61fcaf7/deployments/f9ed02b7-c28e-4df6-83b1-e9553ddd0fc2" } -
Wird verwendet GetDeploymentStatus, um den Status der Bereitstellung abzurufen.
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 Core in der Cloud die Aktion "greengrass:*" als zulässige Aktion vorsieht.
Wenn Sie den Befehl create-deployment zum ersten Mal ausführen, tritt ein ConcurrentDeployment Fehler auf.
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. Vergewissern Sie sich, dass in der aktuellen Version eine Greengrass-Servicerolle mit Ihrer AWS-Konto verknüpft ist. AWS-Region Für weitere Informationen siehe 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 den Aufbau von IoT-Systemen, aber sie erfordern genaue Zeiten auf Servern und Clients. IoT-Geräte sollten die richtige Uhrzeit (innerhalb von 15 Minuten) haben, bevor sie versuchen, eine Verbindung zu AWS IoT Greengrass oder anderen TLS-Diensten herzustellen, die Serverzertifikate verwenden. Weitere Informationen finden Sie im AWS offiziellen Blog unter Verwenden der Gerätezeit zur Validierung von AWS IoT Serverzertifikaten
Die Bereitstellung wird nicht abgeschlossen.
Lösung: Führen Sie die folgenden Schritte aus:
-
Stellen Sie sicher, dass der AWS IoT Greengrass Daemon auf Ihrem Hauptgerät läuft. Führen Sie im Terminal Ihres Hauptgeräts die folgenden Befehle aus, um zu überprüfen, ob der Daemon läuft, und starten Sie ihn bei Bedarf.
So prüfen Sie, ob der Daemon ausgeführt wird:
ps aux | grep -E 'greengrass.*daemon'Wenn die Ausgabe einen
root-Eintrag für/greengrass/ggc/packages/1.11.6/bin/daemonenthält, dann wird der Daemon ausgeführt.Die Version im Pfad hängt von der AWS IoT Greengrass Core-Softwareversion ab, die auf Ihrem Core-Gerät installiert ist.
Um den Daemon zu starten:
cd /greengrass/ggc/core/ sudo ./greengrassd start
-
Stellen Sie sicher, dass Ihr Core-Gerät verbunden ist und die Core-Verbindungsendpunkte ordnungsgemäß konfiguriert sind.
Fehler: Die ausführbaren Java- oder Java8-Dateien konnten nicht gefunden werden, oder der Fehler: Die < Bereitstellungs-ID > des Typs NewDeployment für die < Gruppengruppen-ID ist > fehlgeschlagen. Fehler: Worker mit < Worker-ID konnte nicht initialisiert werden. Grund: Die installierte > Java-Version muss größer oder gleich 8 sein
Lösung: Wenn der Stream Manager für den AWS IoT Greengrass Core aktiviert ist, müssen Sie die Java 8-Runtime 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 Standard-Workflow zur Gruppenerstellung in der AWS IoT Konsole 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 die folgenden Befehle in Ihrem Hauptgerä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 „[ERROR] -Greengrass-Bereitstellungsfehler: Der Bereitstellungsstatus konnte nicht an die Cloud zurückgegeben werden {" deploymentId“: "<deployment-id > „, „errorString“: „PUT konnte nicht initiiert werden, Endpunkt: https://<deployment-status>, error: Put https://deployment-status: proxyconnect tcp: x509: Zertifikat signiert < von > unbekannter Autorität"}“
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 / gespeichert. Wenn Sie den Speicherort auf Ihrem Core-Gerät suchen möchten, überprüfen Sie die Eigenschaft greengrass-root/certs/root.ca.pemcrypto.caPath in der Datei config.json.
Anmerkung
greengrass-rootsteht für den Pfad, in dem die AWS IoT Greengrass Core-Software auf Ihrem Gerät installiert ist. Normalerweise ist dies das Verzeichnis /greengrass.
Fehler: Die < Bereitstellungs-ID > des Typs NewDeployment für die < Gruppengruppen-ID ist > fehlgeschlagen. Fehler bei der Verarbeitung. Die Gruppenkonfiguration ist ungültig: 112 oder [119 0] haben keine RW-Berechtigung für den Pfad „file:“. < >
Lösung: Stellen Sie sicher, dass die Eigentümergruppe des Verzeichnisses Lese- und Schreibberechtigungen für das <path> Verzeichnis hat.
Fehler: < list-of-function-arns > sind so konfiguriert, dass sie als Root ausgeführt werden, aber Greengrass ist nicht für die Ausführung von Lambda-Funktionen mit Root-Rechten konfiguriert.
Lösung: Möglicherweise wird Ihnen diese Fehlermeldung in runtime.log angezeigt, wenn die Bereitstellung fehlschlägt. Stellen Sie sicher, dass Sie die Konfiguration so konfiguriert haben, dass Lambda-Funktionen AWS IoT Greengrass mit Root-Rechten ausgeführt werden können. Ändern Sie entweder den Wert von allowFunctionsToRunAsRoot in yes oder ändern greengrass_root/config/config.json Sie die Lambda-Funktion so, dass sie als andere ausgeführt wird. user/group Weitere Informationen finden Sie unter Eine Lambda-Funktion als Root ausführen.
Fehler: Die < Bereitstellungs-ID > des Typs NewDeployment für die < Gruppengruppen-ID ist > fehlgeschlagen. Fehler bei der Greengrass-Bereitstellung: Der Download-Schritt in der Bereitstellung kann nicht ausgeführt werden. Fehler bei der Verarbeitung: Die heruntergeladene Gruppendatei konnte nicht geladen werden: Die UID konnte nicht anhand des Benutzernamens gefunden werden, Benutzername: ggc_user: Benutzer: unbekannter Benutzer ggc_user.
Lösung: Wenn die Standardzugriffsidentität der Gruppe die Standard-Systemkonten verwendet, müssen der Benutzer und die AWS IoT Greengrass Gruppe auf dem Gerät vorhanden sein. ggc_user ggc_group Anweisungen zum Hinzufügen von Benutzer und Gruppe finden Sie in diesem Schritt. Sie müssen die Namen genau wie gezeigt eingeben.
Fehler: [ERROR] -Laufzeitfehler: Der Lambda-Container kann nicht gestartet werden. {"errorString“: „Container-Mounts konnten nicht initialisiert werden: Greengrass-Root konnte nicht im oberen Verzeichnis des Overlays maskiert werden: Fehler beim Erstellen des Maskengeräts im Verzeichnis ggc-Path: Datei existiert"} < >
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 Verzeichnis im Core-Dateisystem zugreifen kann. /usr 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:
-
/usrals Quellpfad und Zielpfad angeben -
Automatisch Betriebssystem-Gruppenberechtigungen der Linux-Gruppe hinzufügen, zu der die Ressource gehört
-
Seien Sie der Lambda-Funktion zugeordnet und gewähren Sie nur Lesezugriff.
Fehler: Die < Bereitstellungs-ID > des Typs NewDeployment für die < Gruppengruppen-ID ist fehlgeschlagen. Fehler: Prozessstart > fehlgeschlagen: container_linux.go:259: Das Starten des Container-Prozesses verursachte „process_linux.go:250: Das 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: suche nach dem Host-Präfix -ats.iot. <region .amazonaws.com: Kein solcher Host... > [FEHLER] -Greengrass-Bereitstellungsfehler: Der Bereitstellungsstatus konnte nicht an die Cloud zurückgemeldet werden... net/http: Die Anfrage wurde abgebrochen, während auf eine Verbindung gewartet Client.Timeout wurde (beim Warten auf Header wurde sie überschritten)
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. Bei Versuchen, den AWS IoT Greengrass Endpunkt zu erreichen, wird der Host nicht gefunden, sodass Ihre Bereitstellungen im Status bleiben. In
Progress
Sie können die folgenden Befehle und Ausgaben verwenden, um auf dieses Problem zu testen. Ersetzen Sie den region Platzhalter in den Endpunkten durch Ihren. AWS-Region
$ping greengrass-ats.iot.region.amazonaws.com.rproxy.goskope.comping: greengrass-ats.iot.region.amazonaws.com: Name or service not known
$systemd-resolve greengrass-ats.iot.region.amazonaws.com.rproxy.goskope.comgreengrass-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 Problemsystemd.
-
Fügen Sie
DNSSEC=falsezu/etc/systemd/resolved.confhinzu. -
Starten Sie
systemd-resolvedneu.
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 Greengrass Gruppe oder einer 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 der Funktion 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: Die MemorySize Konfiguration für eine Funktion mit der Funktion arn < function-arn > ist in = nicht zulässig. IsolationMode NoContainer
Lösung: Dieser Fehler tritt auf, wenn Sie einen MemorySize Wert angeben und sich für die Ausführung ohne Containerisierung entscheiden. Lambda-Funktionen, die ohne Containerisierung ausgeführt werden, dürfen keine Speicherbeschränkungen haben. Sie können entweder das Limit entfernen oder die Lambda-Funktion so ändern, dass sie in einem Container ausgeführt wird. AWS IoT Greengrass
Fehler: Der Zugriff auf die Sysfs-Konfiguration für eine Funktion mit arn < function-arn > ist in = nicht zulässig. IsolationMode NoContainer
Lösung: Dieser Fehler tritt auf, wenn Sie true for angeben AccessSysfs und sich für die Ausführung ohne Containerisierung entscheiden. Bei Lambda-Funktionen, die ohne Containerisierung ausgeführt werden, muss der Code aktualisiert werden, damit sie direkt auf das Dateisystem zugreifen können. Sie können sie nicht verwenden. AccessSysfs Sie können entweder den Wert false for angeben AccessSysfs oder die Lambda-Funktion so ändern, dass sie in einem Container ausgeführt wird. AWS IoT Greengrass
Fehler: Eine MemorySize Konfiguration für eine Funktion mit arn < function-arn > ist in = erforderlich. IsolationMode GreengrassContainer
Lösung: Dieser Fehler tritt auf, weil Sie kein MemorySize Limit für eine Lambda-Funktion angegeben haben, die Sie in einem Container ausführen. AWS IoT Greengrass Geben Sie einen MemorySize-Wert an, um den Fehler zu beheben.
Fehler: Die Funktion < function-arn > bezieht sich auf eine Ressource des Typs < Resource-Type, > die in = nicht zulässig ist. IsolationMode NoContainer
Lösung: Sie können nicht auf die S3_Object.Generic_Archive RessourcentypenLocal.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 sie in einem Container ausführen. AWS IoT Greengrass Sie können auch direkt auf lokale Geräte zugreifen, wenn sie ohne Containerisierung ausgeführt werden, indem Sie den Code in Ihrer Lambda-Funktion ändern.
Fehler: Die Ausführungskonfiguration für eine Funktion mit der Funktion 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 Sie eine OR-Konfiguration angegeben IsolationMode haben. RunAs Sie müssen die Execution Parameter für diese System-Lambda-Funktion weglassen.
Erkennungsprobleme
Verwenden Sie die folgenden Informationen, um Probleme mit dem AWS IoT Greengrass Discovery-Dienst zu beheben.
Problembereiche
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.
Problembereiche
InvalidMLModelOwner - GroupOwnerSetting wird in der ML-Modellressource bereitgestellt, GroupPermission ist aber GroupOwner oder nicht vorhanden
Lösung: Sie erhalten diesen Fehler, wenn eine Ressource für maschinelles Lernen das ResourceDownloadOwnerSetting Objekt enthält, die erforderliche GroupPermission Eigenschaft GroupOwner oder Eigenschaft jedoch nicht definiert ist. Um dieses Problem zu beheben, definieren Sie die fehlende Eigenschaft.
NoContainer Die Funktion kann beim Anhängen von Ressourcen für maschinelles Lernen keine Berechtigungen konfigurieren. <function-arn > bezieht sich auf die < Ressourcen-ID für maschinelles Lernen mit der entsprechenden Berechtigung in der Ressourcenzugriffsrichtlinie>. < ro/rw >
Lösung: Sie erhalten diesen Fehler, wenn eine nicht containerisierte Lambda-Funktion Berechtigungen auf Funktionsebene für eine Ressource für maschinelles Lernen festlegt. Non-containerized Funktionen müssen Berechtigungen von den Berechtigungen des Ressourcenbesitzers erben, die für die Ressource für maschinelles Lernen definiert sind. Um dieses Problem zu beheben, erben Sie die Berechtigungen des Ressourcenbesitzers (Konsole) oder entfernen Sie die Berechtigungen aus der Ressourcenzugriffsrichtlinie (API) der Lambda-Funktion.
Die Funktion < function-arn > bezieht sich auf die < Ressourcen-ID für maschinelles Lernen > mit fehlender Berechtigung sowohl in der Ressource als auch in der Ressource. ResourceAccessPolicy OwnerSetting
Lösung: Sie erhalten diesen Fehler, wenn die Berechtigungen für die Ressource für maschinelles Lernen nicht für die angehängte Lambda-Funktion oder die Ressource konfiguriert sind. Um dieses Problem zu beheben, konfigurieren Sie die Berechtigungen in der ResourceAccessPolicy Eigenschaft für die Lambda-Funktion oder die OwnerSetting Eigenschaft für die Ressource.
Die Funktion < function-arn > bezieht sich auf die < Ressourcen-ID für maschinelles Lernen > mit der Berechtigung\ "rw\“, während die Einstellung für den Ressourcenbesitzer GroupPermission nur\ "ro\“ zulässt.
Lösung: Sie erhalten diesen Fehler, wenn die für die angehängte Lambda-Funktion definierten Zugriffsberechtigungen die für die Ressource für maschinelles Lernen definierten Ressourcenbesitzerberechtigungen ü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 Die Funktion < function-arn > bezieht sich auf Ressourcen des verschachtelten Zielpfads.
Lösung: Sie erhalten diesen Fehler, wenn mehrere Ressourcen für maschinelles Lernen, die an eine nicht containerisierte Lambda-Funktion angehängt 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 sie dieselbe Gruppenbesitzer-ID verwendet >
Lösung: Sie erhalten diesen Fehler, runtime.log wenn dieselbe Betriebssystemgruppe für die Identität „Als ausführen“ der Lambda-Funktion und als Ressourcenbesitzer für eine Ressource für maschinelles Lernen angegeben ist, die Ressource jedoch nicht an die Lambda-Funktion angehängt ist. Diese Konfiguration gewährt der Lambda-Funktion implizite Berechtigungen, mit denen sie ohne Autorisierung auf die Ressource zugreifen kann. AWS IoT Greengrass
Um dieses Problem zu beheben, verwenden Sie eine andere Betriebssystemgruppe für eine der Eigenschaften oder hängen Sie die Ressource für maschinelles Lernen an die Lambda-Funktion an.
AWS IoT Greengrass Kern bei Docker-Problemen
Verwenden Sie die folgenden Informationen, um Probleme beim Ausführen eines AWS IoT Greengrass Cores in einem Docker-Container zu beheben.
Problembereiche
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 Sie die neueste AWS CLI Version installiert haben (z. B. run:). pip install awscli --upgrade --user Wenn Sie Windows verwenden und die CLI mit dem MSI-Installationsprogramm installiert haben, müssen Sie den Installationsvorgang wiederholen. Weitere Informationen finden Sie im AWS Command Line Interface Benutzerhandbuch AWS Command Line Interface unter Installation von unter Microsoft Windows.
Warnung: IPv4 ist deaktiviert. Das Netzwerk wird nicht funktionieren.
Lösung: Möglicherweise erhalten Sie diese oder eine ähnliche Meldung, wenn Sie das Programm AWS IoT Greengrass auf einem Linux-Computer ausführen. Aktivieren Sie die IPv4-Netzwerkweiterleitung wie in diesem Schritt beschrieben. AWS IoT Greengrass Cloud-Bereitstellung und MQTT-Kommunikation funktionieren nicht, wenn die IPv4-Weiterleitung nicht aktiviert ist. Weitere Informationen finden Sie unter Configure namespaced kernel parameters (sysctls) at runtime
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: User: arn:aws:iam::<account-id>:user/<user-name> is not authorized to perform: ecr: GetAuthorizationToken on resource: * AccessDeniedException
Möglicherweise erhalten Sie diesen Fehler, 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 Zugreifen 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 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 NoContainer Modus befinden, und starten Sie eine neue Bereitstellung. Hängen Sie dann beim Starten des Containers das vorhandene deployment Verzeichnis nicht per Bind-Mount in den AWS IoT Greengrass Core-Docker-Container ein. Erstellen Sie stattdessen ein leeres deployment-Verzeichnis an seiner Stelle und fügen Sie es über Bind-Mount im Docker-Container ein. Dadurch kann der neue Docker-Container die neueste Bereitstellung erhalten, wobei die Lambda-Funktionen im Modus ausgeführt werden. NoContainer
Weitere Informationen finden Sie unter In Ausführung AWS IoT Greengrass in einem Docker-Container.
Fehlerbehebung mit Protokollen
Sie können die Protokollierungseinstellungen für eine Greengrass-Gruppe konfigurieren, z. B. ob Protokolle an Logs gesendet, CloudWatch Protokolle im lokalen Dateisystem gespeichert werden sollen 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 Sie die Protokollierung für AWS IoT Greengrass.
AWS IoT Greengrass Speichert Protokolle auf dem lokalen Dateisystem an den folgenden Speicherorten. Das Lesen der Protokolle auf dem Dateisystem erfordert Root-Berechtigungen.
greengrass-root/ggc/var/log/crash.log-
Zeigt Meldungen an, die generiert werden, wenn ein AWS IoT Greengrass Core abstürzt.
greengrass-root/ggc/var/log/system/runtime.log-
Zeigt Nachrichten zu den fehlgeschlagenen Komponenten an.
greengrass-root/ggc/var/log/system/-
Enthält alle Protokolle von AWS IoT Greengrass Systemkomponenten wie dem Zertifikatsmanager und dem Verbindungsmanager. Mithilfe der Meldungen in
ggc/var/log/system/und sollten Sie herausfinden könnenggc/var/log/system/runtime.log, welcher Fehler in den AWS IoT Greengrass Systemkomponenten aufgetreten ist. greengrass-root/ggc/var/log/system/localwatch/-
Enthält die Protokolle für die AWS IoT Greengrass Komponente, die das Hochladen von Greengrass-Protokollen in Logs verarbeitet. CloudWatch Wenn Sie die Greengrass-Logins nicht sehen können CloudWatch, können Sie diese Protokolle zur Fehlerbehebung verwenden.
greengrass-root/ggc/var/log/user/-
Enthält alle Logs von benutzerdefinierten Lambda-Funktionen. In diesem Ordner finden Sie Fehlermeldungen von Ihren lokalen Lambda-Funktionen.
Anmerkung
Das Standardverzeichnis von /greengrass ist greengrass-root. Wenn ein Schreibverzeichnis konfiguriert wurde, finden Sie auch die Protokolle dort.
Wenn die Protokolle so konfiguriert sind, dass sie in der Cloud gespeichert werden, verwenden Sie CloudWatch Logs, um Protokollmeldungen anzuzeigen. crash.logist nur in den Dateisystemprotokollen auf dem AWS IoT Greengrass Kerngerät zu finden.
Wenn AWS IoT es für das Schreiben von Protokollen konfiguriert ist CloudWatch, überprüfen Sie diese Protokolle, falls Verbindungsfehler auftreten, wenn Systemkomponenten versuchen, eine Verbindung herzustellen AWS IoT.
Weitere Hinweise zur AWS IoT Greengrass Protokollierung finden Sie unterÜberwachen mit AWS IoT Greengrass Protokolle.
Anmerkung
Die Protokolle für die AWS IoT Greengrass Core-Software v1.0 werden im Verzeichnis gespeichert.greengrass-root/var/log
Fehlerbehebung bei Speicherproblemen
Wenn der lokale Dateispeicher voll ist, schlagen einige Komponenten möglicherweise fehl:
-
Es werden keine Updates von lokalen Schatten ausgeführt.
-
Neue AWS IoT Greengrass MQTT-Core-Serverzertifikate können nicht lokal heruntergeladen werden.
-
Die Bereitstellung schlägt fehl.
Sie sollten immer wissen, wie viel lokaler Speicherplatz verfügbar ist. Sie können den freien Speicherplatz auf der Grundlage der Größe der bereitgestellten Lambda-Funktionen, der Protokollierungskonfiguration (sieheFehlerbehebung mit Protokollen) und der Anzahl der lokal gespeicherten Schatten berechnen.
Fehlerbehebung für Nachrichten
Alle lokal gesendeten Nachrichten AWS IoT Greengrass werden mit QoS 0 gesendet. AWS IoT Greengrass Speichert Nachrichten standardmäßig 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 (Version 1.6 oder höher) so konfigurieren, dass Nachrichten im Dateisystem zwischengespeichert werden, sodass sie auch nach einem Neustart des Kerns 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 startet es AWS IoT Greengrass möglicherweise nicht richtig. Weitere Informationen finden Sie unter MQTT-Nachrichtenwarteschlange für Cloud-Ziele.
Anmerkung
Wenn Sie die standardmäßige speicherinterne Warteschlange verwenden, sollten Sie Gruppen bereitstellen oder das Gerät neu starten, wenn die Serviceunterbrechung möglichst gering ist.
Sie können den Core auch so konfigurieren, dass persistente Sitzungen mit AWS IoT eingerichtet werden. Dadurch kann der Core Nachrichten empfangen, die von dem gesendet werden, AWS Cloud während der Core 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 , und fügen Sie ein greengrass-root/configsystem.shadowSyncTimeout-Feld mit einem Zeitüberschreitungswert in Sekunden hinzu. Beispiel:
{ "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.
Anmerkung
Für AWS IoT Greengrass Core-Software v1.6 und früher shadowSyncTimeout ist die Standardeinstellung 1 Sekunde.
Check AWS Betreff: POST
Wenn du dein Problem mit den Informationen zur Fehlerbehebung in diesem Thema nicht lösen kannst, kannst du das Fehlerbehebung AWS IoT Greengrass AWS IoT Greengrass Tag auf AWS re:POST