AWS IoT Greengrass 疑難排解 - AWS IoT Greengrass
AWS IoT Greengrass 核心問題部署問題建立群組和建立函數問題Discovery 問題機器學習資源問題Docker 中的 AWS IoT Greengrass 核心問題日誌故障診斷對儲存體問題進行故障診斷訊息故障診斷陰影同步逾時問題故障診斷檢查 AWS re:Post

AWS IoT Greengrass Version 1 於 2023 年 6 月 30 日進入延長使用壽命階段。如需詳細資訊，請參閱AWS IoT Greengrass V1 維護政策。在此日期之後， AWS IoT Greengrass V1 將不會發行提供功能、增強功能、錯誤修正或安全性修補程式的更新。在上運行的設備 AWS IoT Greengrass V1 不會中斷，並將繼續運行並連接到雲。我們強烈建議您移轉至 AWS IoT Greengrass Version 2，這會增加重要的新功能，並支援其他平台。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

AWS IoT Greengrass 疑難排解

此區段提供故障診斷資訊和可能的解決方案，以協助解決 AWS IoT Greengrass 的相關問題。

如需AWS IoT Greengrass配額 (限制) 的相關資訊，請參閱 Amazon Web Services 一般參考.

AWS IoT Greengrass 核心問題

如果 AWS IoT Greengrass Core 軟體無法啟動，請嘗試下列一般疑難排解步驟：

搜尋下列症狀和錯誤，以尋找有助於疑難排解AWS IoT Greengrass核心問題的資訊。

問題

 

錯誤：組態檔遺失 CaPath、 CertPath 或 KeyPath。Greengrass 協助程式在 [pid = <pid>] 結束狀態下處理。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時，在 crash.log 查看此錯誤。如果您執行的是 1.6 版或更早的版本，也可能會發生這種情況。執行以下任意一項：

  • 升級至 1.7 版或更新版本。我們建議您一律執行 AWS IoT Greengrass 核心軟體的最新版本。如需下載資訊，請參閱 AWS IoT Greengrass 核心軟體。

  • 針對您的 AWS IoT Greengrass 核心軟體版本使用正確的 config.json 格式。如需詳細資訊，請參閱 AWS IoT Greengrass 核心組態檔案。

    注意

    若要找出核心裝置上安裝了哪個版本的 AWS IoT Greengrass 核心軟體，請由您的裝置終端機執行以下命令。

    cd /greengrass-root/ggc/core/
sudo ./greengrassd --version

 

錯誤：無法剖析 /<greengrass-root>/config/config.json。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。請確定 Greengrass 組態檔案使用有效的 JSON 格式。

開啟 config.json (位於 /greengrass-root/config) 並驗證 JSON 格式。例如，確保已正確使用逗號。

 

錯誤：生成 TLS 配置時發生錯誤： ErrUnknownUrisCheme

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。請確定 Greengrass 組態檔案中的 crypto (加密) 區段中的屬性有效。這個錯誤訊息應提供更多資訊。

開啟 config.json (位於 /greengrass-root/config)，並檢查 crypto 區段。例如，憑證和金鑰路徑必須使用正確的 URI 格式，並指向正確的位置。

 

錯誤：執行時間無法開始：無法啟動工作者：容器測試逾時。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。在 Greengrass 配置文件中設置postStartHealthCheckTimeout屬性。此選用屬性會設定 Greengrass 協助程式等候後置開始健康狀況檢查完成的時間量 (毫秒)。預設值為 30 秒 (30000 毫秒)。

開啟 config.json (位於 /greengrass-root/config)。在 runtime 物件上，新增 postStartHealthCheckTimeout 屬性並將值設為大於 30000。視需要插入逗號以建立有效的 JSON 文件。例如：

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

 

<address>錯誤： PutLogEvents在本地雲觀察上調用失敗，logGroup：/GreengrassSystem/連接管理器，錯誤：：發送請求失敗，原因是 RequestError：發布 HTTP：///<path>雲觀察/日誌/：撥打 tcp：getsockopt：連接被拒絕，響應：{}。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。如果您在 Raspberry Pi 上執行 AWS IoT Greengrass，而且未完成所需的記憶體設定，可能會發生這種情況。如需有關此步驟的詳細資訊，請參閱此步驟。

 

<region><account-id><function-name><version><file-name>錯誤：無法創建服務器，原因是：加載組失敗：chmod/<greengrass-root>ggc /部署/lambda /ARN：aw:lambda::: 函數::/：沒有這樣的文件或目錄。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。如果您將 Lambda 可執行檔部署到核心，請檢查group.json檔案中的函數Handler屬性 (位於/greengrass- root /ggc/部署/群組)。若處理常式不是您所編譯可執行檔的完全相符名稱，則請以空白 JSON 物件 ({}) 取代 group.json 檔案的內容，並執行以下命令來啟動 AWS IoT Greengrass：

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

然後，使用 AWS Lambda API 更新函數組態的 handler 參數，發佈新功能版本和更新別名。如需詳細資訊，請參閱 AWS Lambda 函數版本控制和別名。

假設您已透過別名 (建議) 新增函數到 Greengrass，那麼您現在可以重新部署您的群組。(若否，您必須在您的群組定義和訂閱中指向新的函數版本或別名，才能部署群組。)

 

在您從無容器化的情況下執行變更為在 Greengrass 容器中執行後，AWS IoT Greengrass 核心軟體沒有啟動。

解決方案：檢查您沒有遺漏任何容器相依性。

 

錯誤：多工緩衝處理應至少為 262144 位元組。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。開啟 group.json 檔案 (位於 /greengrass-root/ggc/deployment/group)、以空的 JSON 物件 ({}) 取代檔案的內容，並執行下列命令來啟動 AWS IoT Greengrass：

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

然後依照 在本機儲存快取訊息 程序中的步驟操作。對於 GGCloudSpooler 函數，請務必指定大於或等於 262144 的 GG_CONFIG_MAX_SIZE_BYTES 值。

 

錯誤：[ERROR]-雲端傳訊錯誤：嘗試發佈訊息時發生錯誤。{"errorString": "操作逾時"}

解決方案：當 Greengrass 核心無法傳送 MQTT 訊息給 AWS IoT Core 時，您可能會在 GGCloudSpooler.log 中看到此錯誤。如果核心環境的頻寬有限又有高延遲，就可能發生這種情況。如果您正在運行 AWS IoT Greengrass v1.10.2 或更高版本，請嘗試增加 config. json 文件中的mqttOperationTimeout值。如果該屬性不存在，請將其新增到 coreThing 物件。例如：

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

預設值為 5，最小值為 5。

 

錯誤：container_linux.go:344：啟動容器程序造成 "process_linux.go:424：容器 init 造成 \"rootfs_linux.go:64：將 \\\"/greengrass/ggc/socket/greengrass_ipc.sock\\\" 裝載至 rootfs \\\"/greengrass/ggc/packages/<version>/rootfs/merged\\\" (位於 \\\"/greengrass_ipc.sock\\\") 造成 \\\"stat /greengrass/ggc/socket/greengrass_ipc.sock: permission denied\\\"\""。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時，在 runtime.log 查看此錯誤。如果您的 umask 高於 0022，就會發生此情形。若要解決這個問題，您必須將 umask 設定為 0022 或更低。數值 0022 預設會授予所有人讀取新檔案的許可。

 

錯誤：具 PID：<process-id> 的執行中 Greengrass 協助程式。有些系統元件無法啟動。檢查 'runtime.log' 是否有錯誤。

解決方案：您可以在 AWS IoT Greengrass 核心軟體沒有啟動時查看此錯誤。檢查 runtime.log 和 crash.log 是否有特定的錯誤資訊。如需詳細資訊，請參閱 日誌故障診斷。

 

裝置陰影與雲端不同步。

解決方案：確定AWS IoT Greengrass具有 Greengrass 服務角色中的權限iot:UpdateThingShadow和iot:GetThingShadow動作。如果服務角色使用 AWSGreengrassResourceAccessRolePolicy 受管政策，預設會包含這些權限。

請參閱 陰影同步逾時問題故障診斷。

 

錯誤：無法接受 TCP 連線。接受 tcp [::]:8000: accept4: 太多開啟的檔案。

解決方案：您可以在 greengrassd 指令碼輸出中查看此錯誤。如果 AWS IoT Greengrass 核心軟體的檔案描述項限制已達閾值且需要提高此限制，可能會發生這種狀況。

使用以下命令，然並重新啟動 AWS IoT Greengrass 核心軟體。

ulimit -n 2048
注意

在此範例中，將提高限制到 2048。請為您使所用的案例選擇適當的數值。

 

錯誤：執行時間執行錯誤：無法啟動 lambda 容器。container_linux.go:259：啟動容器程序造成 "process_linux.go:345：容器 init 造成 \"rootfs_linux.go:50：準備 rootfs 造成 \\\"permission denied\\\"\""。

解決方案：直接將 AWS IoT Greengrass 安裝在根目錄之下，或確保 AWS IoT Greengrass 核心軟體安裝所在的目錄及其父目錄擁有每個人的 execute 許可。

 

警告:[WARN]-[5] GK 遠端：擷取公開金鑰資料時發生錯誤: ErrPrincipalNotConfigured: 未設定的 MqttCertificate 私密金鑰。

解決方案：AWS IoT Greengrass 使用常見的處理常式來驗證所有安全性主體的屬性。runtime.log 中的這個警告是預期的，除非您已為本機 MQTT 伺服器指定自訂私有金鑰。如需詳細資訊，請參閱 AWS IoT Greengrass 核心安全性主體。

 

<account-id><role-name><region>錯誤：嘗試使用角色 arn: aw:iam::: 角色/訪問 s3 網址 https://-綠色更新時的權限被拒絕。 <region><architecture><distribution-version>. 亞馬遜公司/核心//大核心-.

解決方案：當 over-the-air (OTA) 更新失敗時，您可能會看到此錯誤。在簽署者角色原則中，將目標新增AWS 區域為Resource. 簽署者角色用於預先簽署 S3 URL，以便進行 AWS IoT Greengrass 軟體更新。如需詳細資訊，請參閱 S3 URL 簽署者角色。

 

AWS IoT Greengrass核心設定為使用網路代理伺服器，而您的 Lambda 函數無法建立傳出連線。

解決方案：根據您的執行階段和 Lambda 函數用來建立連線的可執行檔，您可能也會收到連線逾時錯誤。請確定您的 Lambda 函數使用適當的代理伺服器組態，透過網路代理伺服器連線。 AWS IoT Greengrass透過http_proxy、https_proxy和no_proxy環境變數，將代理組態傳遞給使用者定義的 Lambda 函數。存取方式如下面 Python 程式碼片段所示。

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

大小寫請與環境中定義的變數相同，例如全部小寫的 http_proxy 或全部大寫的 HTTP_PROXY。對於這些變數，AWS IoT Greengrass 兩者都支援。

注意

大多數用來連線的程式庫 (例如 boto3 或 cURL 和 python requests 套件)，預設會使用這些環境變數。

 

此核心位於連線/中斷連線的無限迴圈。runtime.log 檔案包含連線和中斷連線項目的連續系列。

解決方案：如果另一個裝置以硬式編碼為使用核心物件名稱做為對 AWS IoT 之 MQTT 連線的用戶端 ID，可能會發生這種情形。同時連接在相同的AWS 區域，AWS 帳戶必須使用唯一的客戶端 ID。在預設情況下，核心使用核心物件名稱做為這些連線的用戶端 ID。

若要解決這個問題，您可以變更其他裝置用於連線的用戶端 ID (建議使用)，或覆寫核心的預設值。

覆寫核心裝置的預設用戶端 ID

  1. 執行下列命令以停止 Greengrass 常駐程式：

    cd /greengrass-root/ggc/core/
sudo ./greengrassd stop

  2. 開放 greengrass-root/config/config.json 由 su 使用者編輯。

  3. 在 coreThing 物件中，新增 coreClientId 屬性，並將值設定為您的自訂用戶端 ID。值必須介於 1 到 128 個字元之間。在目前的中，它必須是唯一AWS 區域的AWS 帳戶。

    "coreClientId": "MyCustomClientId"

  4. 啟動協助程式。

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

 

錯誤 : 無法啟動 lambda 容器。container_linux.go: 259: 啟動容器程序導致「process_linux.go: 345: container init 導致「rootfs_linux.go: 62: 將「proc」掛載到 rootfs」

解決方案：在某些平台上，您可能會在嘗AWS IoT Greengrass試掛載/proc檔案系統以建立 Lambda 容器runtime.log時看到此錯誤。或可能出現類似錯誤 , 例如 operation not permitted 或 EPERM。即使依相依性檢查程式指令碼在平台上執行的測試完全通過，這些錯誤也可能會發生。

請嘗試下列其中一種可能的解決方案 :

  • 在 Linux 核心中啟用 CONFIG_DEVPTS_MULTIPLE_INSTANCES 選項。

  • 主機上的 /proc 掛載選項只能設為 rw,relatim。

  • 將 Linux 核心升級至 4.9 版或更新版本。

注意

這個問題與掛載 /proc 以提供本機資源存取無關。

 

[錯誤]-運行時執行錯誤：無法啟動 lambda 容器。 {"ErrorString"：「無法初始化容器掛載：無法在覆蓋上部目錄中掩蓋 greengrass 根目錄：無法在目錄中創建掩碼設備<ggc-path>：文件存在"}

解決方案：部署失敗時，您可能會在 runtime.log 中看到此錯誤。如果AWS IoT Greengrass群組中的 Lambda 函數無法存取核心檔案系統中的/usr目錄，就會發生此錯誤。

若要解決這個問題，請將本機磁碟區資源新增至群組，然後部署群組。此資源必須：

  • 指定 /usr 作為來源路徑和目的地路徑。

  • 為擁有資源的 Linux 群組自動新增作業系統群組許可。

  • 與 Lambda 函數相關聯，並允許唯讀存取。

 

[錯誤]-部署失敗。 {"deploymentId」: <deployment-id>「,「錯誤字符串」:「PID <pid>失敗的容器測試過程:容器進程狀態:退出狀態 1"}

解決方案：部署失敗時，您可能會在 runtime.log 中看到此錯誤。如果AWS IoT Greengrass群組中的 Lambda 函數無法存取核心檔案系統中的/usr目錄，就會發生此錯誤。

您可以通過檢查其他錯誤來確認是否GGCanary.log存在這種情況。如果 Lambda 函數無法訪問該/usr目錄，GGCanary.log將包含以下錯誤：

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

若要解決這個問題，請將本機磁碟區資源新增至群組，然後部署群組。此資源必須：

  • 指定 /usr 作為來源路徑和目的地路徑。

  • 為擁有資源的 Linux 群組自動新增作業系統群組許可。

  • 與 Lambda 函數相關聯，並允許唯讀存取。

 

解決方案：當 AWS IoT Greengrass Core 軟體無法啟動時，您可能會在runtime.log檔案中看到此錯誤。這個問題在 Debian 作業系統上可能比較常見。

要解決此問題，請依照下列步驟：

  1. 將AWS IoT Greengrass核心軟體升級至 v1.9.3 或更新版本。這應該會自動解決此問題。

  2. 如果您在升級AWS IoT Greengrass核心軟體之後仍然看到這個錯誤，請在 config.json 檔案true中將system.useOverlayWithTmpfs屬性設定為。

    範例
    {
  "system": {
    "useOverlayWithTmpfs": true
  },
  "coreThing": {
    "caPath": "root-ca.pem",
    "certPath": "cloud.pem.crt",
    "keyPath": "cloud.pem.key",
    ...
  },
  ...
}
注意

錯誤訊息中會顯示您的 AWS IoT Greengrass Core 軟體版本。若要尋找您的 Linux 核心版本，請執行 uname -r。

 

錯誤 : [DEBUG]-無法取得路由。捨棄訊息。

解決方案：檢查您群組中的訂閱，並確認該訂閱有列在 [DEBUG] 訊息中。

 

錯誤:[Errno 24] 太多開啟的 <lambda-function>，[Errno 24] 太多開啟的檔案

解決方案：如果函數在函數處理常式中具現化，您可能會在 Lambda 函數記錄檔StreamManagerClient中看到此錯誤。我們建議您將用戶端建立處理常式之外。如需詳細資訊，請參閱 使用 StreamManagerClient 使用串流。

 

錯誤：DS 服務器無法開始監聽套接字：監聽 Unix <ggc-path>/ggc /插座/greengrass_ipc.sock：綁定：無效的參數

解決方案：當 AWS IoT Greengrass Core 軟體無法啟動時，您可能會看到此錯誤。當AWS IoT Greengrass核心軟體安裝到具有較長檔案路徑的資料夾時，就會發生此錯誤。重新安裝AWS IoT Greengrass核心軟件的文件路徑具有少於 79 字節的文件夾，如果你不使用寫目錄，或 83 字節，如果你使用寫目錄。

[信息]（複印機）要點。 StreamManager：標準輸出。由以下原因引起：傑克遜。 JsonMappingException：即時超過最小或最大瞬間

當您將AWS IoT Greengrass核心軟體升級至 v1.11.3 時，如果串流管理員無法啟動，您可能會在串流管理員記錄檔中看到下列錯誤。

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}

如果您使用的是 v1.11.3 以上的AWS IoT Greengrass核心軟體版本，並且想要升級至更新版本，請使用 OTA 更新來升級至 1.11.4 版。

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

當您apt update在從 APT 存放庫安裝AWS IoT Greengrass核心軟體的裝置上執行時，可能會看到下列錯誤。

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

發生此錯誤是因為AWS IoT Greengrass不再提供從 APT 存放庫安裝或更新AWS IoT Greengrass核心軟體的選項。若要成功執行apt update，請從裝置的來源清單中移除AWS IoT Greengrass存放庫。

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

部署問題

使用以下資訊協助您排解部署的故障問題。

問題

 

您目前的部署無法運作，因此您想要回復到之前可正常運作的部署。

解決方案：使用AWS IoT主控台或 AWS IoT Greengrass API 重新部署先前的工作部署。這會將對應的群組版本部署至您的核心裝置。

重新部署 (主控台)

  1. 在 [群組組態] 頁面上，選擇 [部署] 索引標籤。此頁面會顯示群組的部署歷史記錄，包括日期和時間、群組版本，以及每個部署嘗試的狀態。

  2. 尋找您要重新部署的資料列。選取要重新部署的部署，然後選擇重新部署。

    顯示重新部署動作以進行部署的部署頁面。
重新部署 (CLI)

  1. 用ListDeployments於尋找您要重新部署的部署 ID。例如：

    aws greengrass list-deployments --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7

    命令會傳回群組的部署清單。

    {
    "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"
        }
    ]
}
    注意

    這些 AWS CLI 命令對群組和部署 ID 使用範例值。當您執行命令時，請務必取代範例值。

  2. 用CreateDeployment於重新部署目標部署。將部署類型設定為 Redeployment。例如：

    aws greengrass create-deployment --deployment-type Redeployment \ 
  --group-id 74d0b623-c2f2-4cad-9acc-ef92f61fcaf7 \
  --deployment-id f8e4c455-8ac4-453a-8252-512dc3e9c596

    命令會傳回新部署的 ARN 和 ID。

    {
    "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"
}

  3. 用GetDeploymentStatus於取得部署狀態。

 

您會在日誌中看到部署 403 Forbidden (403 禁止) 錯誤。

解決方案：確定雲端中AWS IoT Greengrass核心的原則包含"greengrass:*"為允許的動作。

 

第一次執行建立部署命令時，就會發生 ConcurrentDeployment 錯誤。

解決方案：部署可能在進行中。您可以執行 get-deployment-status 查看是否已建立部署。如果尚未建立，可以再建立一次部署。

 

錯誤：Greengrass 未獲授權，無法擔任與此帳戶關聯的服務角色，或錯誤：失敗：TES 服務角色並未與此帳戶關聯。

解決方案：部署失敗時，您可能會看到此錯誤。檢查 Greengrass 服務角色是否與您AWS 帳戶在目前的服務角色相關聯。AWS 區域如需詳細資訊，請參閱 管理 Greengrass 服務角色 (CLI) 或 管理 Greengrass 服務角色 (主控台) 。

 

錯誤：無法在部署中執行下載步驟，下載時發生錯誤：下載群組定義檔案時發生錯誤：... x509：憑證已過期或無效

解決方案： 您可以在部署失敗時，在 runtime.log 查看此錯誤。如果您收到 Deployment failed 錯誤，其包含訊息 x509: certificate has expired or is not yet valid，請檢查裝置時鐘。TLS 和 X.509 憑證提供安全基礎以便建置 IoT 系統，但是這些憑證在伺服器和用戶端上需要準確的時間。IoT 裝置應該具有正確的時間 (15 分鐘內)，才能嘗試連線至 AWS IoT Greengrass 或其他使用伺服器憑證的 TLS 服務。如需詳細資訊，請參閱AWS官方部落格上的使用裝置時間驗證物聯網上的AWS IoT伺服器憑證。

 

部署尚未完成。

解決方案：執行下列動作：

  • 請確認 AWS IoT Greengrass 協助程式有在您的核心裝置上執行作業。在核心裝置終端機中，執行下列命令以檢查協助程式是否正在執行，並在需要時啟動它。

    1. 檢查精靈是否有在運作：

      ps aux | grep -E 'greengrass.*daemon'

      若輸出的 root 含有 /greengrass/ggc/packages/1.11.6/bin/daemon 項目，則精靈有在運作。

      路徑的版本取決於安裝在您的核心裝置中的 AWS IoT Greengrass 核心軟體版本。

    2. 若要啟動協助程式：

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

  • 確保您的核心裝置已連線，且核心連線端點的設定都正確。

 

錯誤：無法找到 java 或 java8 可執行文件，或錯誤：<deployment-id>組的類型部署<group-id>失敗錯誤：無法以<worker-id>原因初始化的 Worker 安裝的 Java 版本必須大 NewDeployment 於或等於 8

解決方案：如果核心已啟用串流管理員，您必須先在AWS IoT Greengrass核心裝置上安裝 Java 8 執行階段，然後再部署群組。如需詳細資訊，請參閱串流管理員的需求。當您在AWS IoT主控台中使用預設群組建立工作流程建立群組時，預設情況下會啟用串流管理員。

或者，可以停用串流管理員，然後部署群組。如需詳細資訊，請參閱 設定串流管理員設定 (主控台)。

 

此部署沒有完成，且 runtime.log 含有多個「等待 1 秒讓容器停止」項目。

執行時間：在您的核心裝置終端機執行下列命令以重新啟動 AWS IoT Greengrass 協助程式。

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

 

部署未完成，且 runtime.log 包含 "[ERROR]-Greengrass 部署錯誤：無法將部署狀態回報給雲端 {"deploymentId": "<deployment-id>", "errorString": "無法初始化 PUT，端點: https://<deployment-status>，錯誤: Put https://<deployment-status>: proxyconnect tcp: x509: 未知授權機構簽署的憑證"}"

解決方案：當 Greengrass 核心設定為使用 HTTPS Proxy 連線，且系統上的 Proxy 伺服器憑證鏈結不受信任時，您可能會在 runtime.log 檔案中看到此錯誤。若要嘗試解決這個問題，請將憑證鏈結新增至根 CA 憑證。Greengrass 核心會將此檔案的憑證新增至 HTTPS 和 MQTT 與 AWS IoT Greengrass 的連線中用於 TLS 驗證的憑證集區。

下列範例顯示新增至根 CA 憑證檔案的 Proxy 伺服器 CA 憑證：

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

根 CA 憑證檔案預設位於 /greengrass-root/certs/root.ca.pem 中。要在您的核心設備上查找位置，請檢查 config. json 中的crypto.caPath屬性。

注意

greengrass-root 代表 AWS IoT Greengrass 核心軟體在裝置上安裝所在的路徑。通常，這是 /greengrass 目錄。

 

<path>錯誤：<deployment-id>組 NewDeployment 的類型部署<group-id>失敗錯誤：處理時出錯。組配置無效：112 或 [119 0] 沒有對文件的 rw 權限：。

解決方案：確保 <path> 目錄的擁有者群組具有讀取目錄和寫入目錄許可。

 

錯誤：< list-of-function-arns > 設定為以 root 身分執行，但 Greengrass 未設定為以根權限執行 Lambda 函數。

解決方案： 您可以在部署失敗時，在 runtime.log 查看此錯誤。請確定您已設定AWS IoT Greengrass為允許 Lambda 函數以根權限執行。greengrass_root/config/config.json將 allowFunctionsToRunAsRoot in 的值變更為，yes或將 Lambda 函數變更為以其他使用者/群組身分執行。如需詳細資訊，請參閱 以根身份運行 Lambda 函數。

 

錯誤：<deployment-id>組的類型 NewDeployment 部署<group-id>失敗錯誤：Greengrass 部署錯誤：無法在部署中執行下載步驟。處理時出錯：無法加載下載的組文件：無法根據用戶名找到 UID，用戶 userName：ggc_user：用戶：未知用戶 ggc_user。

解決方案：如果AWS IoT Greengrass群組的預設存取身分使用標準系統帳戶，則該使用ggc_user者和ggc_group群組必須存在於裝置上。如需展示如何新增使用者和群組的指示，請參閱此步驟。請務必輸入完全如所示的名稱。

 

錯誤：[ERROR] 執行時間執行錯誤：無法啟動 lambda 容器。{"errorString"："無法初始化容器掛載：無法在覆蓋上層目錄中遮罩 Greengrass 根目錄：無法在目錄 <ggc-path> 上建立遮罩裝置：檔案存在"}

解決方案： 您可以在部署失敗時，在 runtime.log 查看此錯誤。如果 Greengrass 群組中的 Lambda 函數無法存取核心檔案系統中的/usr目錄，就會發生這個錯誤。若要解決這個問題，請將本機磁碟區資源新增至群組，然後部署群組。資源必須：

  • 指定 /usr 作為來源路徑和目的地路徑。

  • 為擁有資源的 Linux 群組自動新增作業系統群組許可。

  • 與 Lambda 函數相關聯，並允許唯讀存取。

 

錯誤：<deployment-id>組的類型部署<group-id>失敗錯誤：進程啟動失敗：容器 _linux.go：259：啟動容器進程導致「process_linux.go：250： NewDeployment 對初始化運行執行 exec 集進程導致\」等待：沒有子進程\「」。

解決方案：部署失敗時，您可能會看到此錯誤。重新嘗試部署。

 

<host-prefix>錯誤：[警告]-MQTT [客戶端] 撥打 TCP：查找- <region>. 亞馬遜:沒有這樣的主機... [錯誤]-Greengrass 部署錯誤：無法將部署狀態報告回雲... net/http：請求在等待連接時取消（等待標題時超過客戶端。超過超出超過超出）

解決方案：如果您使用 systemd-resolved，根據預設啟用 DNSSEC 設定，則可能會看到此錯誤。因此，無法辨識許多公有網域。嘗試連接 AWS IoT Greengrass 端點無法找到主機，因此您的部署仍處於 In Progress 狀態。

您可以使用下列命令和輸出，來測試是否有此問題。將端點中的區域預留位置取代為您的AWS 區域.

$ 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

可能的解決方案是停用 DNSSEC。當 DNSSEC 為 false 時，不會進行 DNSSEC 驗證。如需詳細資訊，請參閱的這個已知問題systemd。

  1. 將 DNSSEC=false 新增至 /etc/systemd/resolved.conf。

  2. 重新啟動 systemd-resolved。

如需 resolved.conf 和 DNSSEC 的詳細資訊，請在終端機中執行 man resolved.conf。

 

建立群組和建立函數問題

您可以使用下列資訊來協助疑難排解建立AWS IoT Greengrass群組或 Greengrass Lambda 函數的問題。

 

錯誤：群組的 IsolationMode '' 設定無效。

解決方案：不支援 function-definition-version 的 DefaultConfig 中的 IsolationMode 值時，可能會發生此錯誤。支援的值為 GreengrassContainer 和 NoContainer。

 

錯誤：使用 arn 函數的 IsolationMode '' 配置<function-arn>無效。

解決方案：不支援 function-definition-version 的 <function-arn> 中的 IsolationMode 值時，可能會發生此錯誤。支援的值為 GreengrassContainer 和 NoContainer。

 

錯 MemorySize誤：<function-arn>在 IsolationMode = NoContainer 中不允許使用 arn 的函數配置。

解決方案：當您指定MemorySize值並選擇在不使用容器化的情況下執行時，就會發生此錯誤。在沒有容器化的情況下執行的 Lambda 函數不能有記憶體限制。您可以移除限制，也可以將 Lambda 函數變更為在AWS IoT Greengrass容器中執行。

 

錯誤：在 = 中<function-arn>不允許使用 arn 的函數訪問 Sysfs 配置。 IsolationMode NoContainer

解決方案：當您指定true為AccessSysfs並選擇在不使用容器化的情況下執行時，就會發生此錯誤。在沒有容器化的情況下執行的 Lambda 函數必須更新其程式碼才能直接存取檔案系統，而且無法使用。AccessSysfs您可以將值指定false為，也可AccessSysfs以將 Lambda 函數變更為在AWS IoT Greengrass容器中執行。

 

錯 MemorySize誤：<function-arn>在 IsolationMode = GreengrassContainer 中需要使用 arn 的函數配置。

解決方案：發生此錯誤的原因是您未針對在AWS IoT Greengrass容器中執行的 Lambda 函數指定MemorySize限制。指定 MemorySize 值以解決錯誤。

 

錯誤：函數<function-arn><resource-type>是指 IsolationMode = 中不允許的類型資源NoContainer。

解決方案：如果您在沒有容器化的情況下執行 Lambda 函數，則無法存Local.Device取ML_Model.S3_Object、、或S3_Object.Generic_Archive資源類型。Local.Volume ML_Model.SageMaker.Job若您需要這些資源類型，您必須在 AWS IoT Greengrass 容器中執行。您也可以透過變更 Lambda 函數中的程式碼，在執行時直接存取本機裝置，而不需要容器化。

 

錯誤：不允許 arn 為 <function-arn> 的函數執行組態。

解決方案：當您使用或建立系統 Lambda 函數，GGCloudSpooler並指定GGIPDetectorIsolationMode或RunAs組態時，就會發生此錯誤。您必須省略此系統 Lambda 函Execution數的參數。

 

Discovery 問題

使用下列資訊來協助您排除 AWS IoT Greengrass Discovery Service 的問題。

 

錯誤：裝置是太多群組的成員，裝置不得在超過 10 個群組中

解決方案：這是已知的限制。用戶端裝置最多可以是 10 個群組的成員。

 

機器學習資源問題

使用下列資訊協助疑難排解機器學習資源的問題。

 

無效 ML ModelOwner - GroupOwnerSetting 在 ML 模型資源中提供，但 GroupOwner 或 GroupPermission 不存在

解決方案：如果機器學習資源包含ResourceDownloadOwnerSetting物件，但未定義必要GroupOwner或GroupPermission屬性，則會收到此錯誤。若要解決此問題，請定義遺失的屬性。

 

NoContainer 附加 Machine Learning 資源時，函數無法配置權限。 <function-arn>是指在資源存取原則中<resource-id>具有權限 <ro/rw> 的機器學習資源。

解決方案：如果非容器化 Lambda 函數指定了機器學習資源的函數層級許可，您會收到此錯誤。非容器化函數必須從機器學習資源上定義的資源擁有者權限繼承權限。若要解決此問題，請選擇繼承資源擁有者權限 (主控台)，或從 Lambda 函數的資源存取原則 (API) 移除權限。

 

函數<function-arn>是指<resource-id>與資源中缺少權限的 Machine L ResourceAccessPolicy earning 資源 OwnerSetting。

解決方案：如果未針對連接的 Lambda 函數或資源設定機器學習資源的權限，您會收到此錯誤。若要解決此問題，請在 Lambda 函數或資源OwnerSetting屬性的屬性中設定權限。ResourceAccessPolicy

 

函數<function-arn>是指<resource-id>具有\ "rw\" 權限的 Machine Learning 資源，而資源擁有者設定 GroupPermission僅允許\ "ro\"。

解決方案：如果為連接的 Lambda 函數定義的存取權限超過針對機器學習資源定義的資源擁有者權限，則會收到此錯誤。若要解決此問題，請為 Lambda 函數設定更嚴格的權限，或為資源擁有者設定限制較少的權限。

 

NoContainer 函數<function-arn>是指嵌套目標路徑的資源。

解決方案：如果連接至非容器化 Lambda 函數的多個機器學習資源使用相同的目標路徑或巢狀目標路徑，則會收到此錯誤。若要解決此問題，請為資源指定個別目的地路徑。

 

Lambda <function-arn> 透過共用相同群組擁有者 ID 來獲得資源 <resource-id> 的存取權

解決方案：runtime.log如果將相同的作業系統群組指定為 Lambda 函數的執行身分識別和機器學習資源的資源擁有者，但資源未附加至 Lambda 函數，則您會收到此錯誤。此組態提供 Lambda 函數隱含許可，可用來存取資源而無需AWS IoT Greengrass授權。

若要解決此問題，請針對其中一個屬性使用不同的作業系統群組，或將機器學習資源附加至 Lambda 函數。

Docker 中的 AWS IoT Greengrass 核心問題

使用下列資訊可協助疑難排解在 Docker 容器中執行AWS IoT Greengrass核心的問題。

 

錯誤：未知的選項：-no-include-email。

解決方案：執行 aws ecr get-login 命令時，可能會發生此錯誤。請確定您已安裝最新的 AWS CLI 版本 (例如，執行：pip install awscli --upgrade --user)。如果您使用 Windows 並已使用 MSI 安裝程式安裝 CLI，您必須重新啟動安裝程序。如需詳細資訊，請參閱AWS Command Line Interface使用者指南中的AWS Command Line Interface在 Microsoft 視窗上安裝。

 

警告：IPv4 已停用。網路將無法運作。

解決方案：在 Linux 電腦上執行 AWS IoT Greengrass 時，可能會收到此警告或類似訊息。請依此步驟所述啟用 IPv4 網路轉寄。AWS IoT Greengrass 雲端部署和 MQTT 通訊無法在未啟用 IPv4 轉寄時使用。如需詳細資訊，請參閱 Docker 文件中的在執行時間設定命名空間核心參數 (sysctls)。

 

錯誤：防火牆封鎖了 Windows 和容器之間的檔案共用。

解決方案：在 Windows 電腦上執行 Docker 時，您可能收到此錯誤或 Firewall Detected 訊息。如果您登入虛擬私有網路 (VPN)，而您的網路設定防止掛載共用磁碟機，也可能會發生這個錯誤。在這種情況下，請關閉 VPN 並重新執行 Docker 容器。

 

錯誤：呼叫 GetAuthorizationToken 作業時發生錯誤 (AccessDeniedException)：User: arn: aw:iam::: user/ <account-id><user-name>未授權在資源上執行:ecr: * GetAuthorizationToken

如果您沒有足夠的權限存取 Amazon ECR 儲存庫，則在執行aws ecr get-login-password命令時可能會收到此錯誤。如需詳細資訊，請參閱 Amazon ECR 儲存庫政策範例和存取 Amazon ECR 使用者指南中的一個 Amazon ECR 儲存庫。

 

錯誤：無法為服務 greengrass 建立容器：衝突。容器名稱「/aws-iot-greengrass" 已在使用中。

解決方案：當容器名稱由舊版容器使用時，可能會發生這種情況。若要解決這個問題，請執行以下命令來移除舊的 Docker 容器：

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

 

錯誤：[FATAL]-因為意外錯誤，無法重設執行緒的掛載命名空間：「不允許操作」。為了保持一致性，GGC 會當機且需要手動重新啟動。

解決方案：當runtime.log您嘗試將 GreengrassContainer Lambda 函數部署到 Docker 容器中執行的AWS IoT Greengrass核心時，可能會發生此錯誤。目前，只有 NoContainer Lambda 函數可以部署到 Greengrass 碼頭容器。

若要解決此問題，請確定所有 Lambda 函數都處於NoContainer模式，然後開始新的部署。然後，在啟動容器時，請勿將現有deployment目錄繫結掛載到AWS IoT Greengrass核心 Docker 容器上。而是建立一個空的 deployment 目錄來取代並在 Docker 容器中綁定掛載該目錄。這可讓新的 Docker 容器接收以NoContainer模式執行 Lambda 函數的最新部署。

如需詳細資訊，請參閱 在 Docker 容器中執行 AWS IoT Greengrass。

日誌故障診斷

您可以設定 Greengrass 群組的記錄設定，例如是要將記錄檔傳送到記錄檔、將記錄檔儲存在本機檔案系統上，或同時儲存兩者。 CloudWatch 若要在問題故障診斷時取得詳細資訊，您可以暫時將記錄層級變更為 DEBUG。對記錄設定所做的變更會在部署群組時生效。如需詳細資訊，請參閱 設定 AWS IoT Greengrass 的日誌記錄。

AWS IoT Greengrass 將日誌存放在本機檔案系統的下列位置。在檔案系統中讀取日誌需要根許可。

greengrass-root/ggc/var/log/crash.log

顯示AWS IoT Greengrass核心當機時產生的訊息。

greengrass-root/ggc/var/log/system/runtime.log

顯示元件故障的訊息。

greengrass-root/ggc/var/log/system/

包含來自 AWS IoT Greengrass 系統元件的所有日誌，例如憑證管理器和連線管理器。若要使用在 ggc/var/log/system/ 和 ggc/var/log/system/runtime.log 中使用訊息，您應該要能找出在 AWS IoT Greengrass 系統元件發生的錯誤。

greengrass-root/ggc/var/log/system/localwatch/

包含處理將 Greengrass 記錄檔上傳到記錄檔的AWS IoT Greengrass元件的記錄檔。 CloudWatch 如果您無法檢視 Greengrass 登入 CloudWatch，則可以使用這些記錄檔進行疑難排解。

greengrass-root/ggc/var/log/user/

包含使用者定義 Lambda 函數的所有記錄 核取此資料夾以尋找本機 Lambda 函數中的錯誤訊息。

注意

在預設情況下，greengrass-root 即為 /greengrass 目錄。如果已設定好寫入目錄，那麼日誌就會位在該目錄中。

如果記錄設定為儲存在雲端，請使用 CloudWatch 記錄檔來檢視記錄訊息。 crash.log只能在AWS IoT Greengrass核心裝置上的檔案系統記錄檔中找到。

如果設定AWS IoT為將記錄寫入 CloudWatch，如果系統元件嘗試連線時發生連線錯誤，請檢查這些記錄檔AWS IoT。

如需有關 AWS IoT Greengrass 記錄的詳細資訊，請參閱 使用 AWS IoT Greengrass 日誌進行監控。

注意

AWS IoT Greengrass 核心軟體 1.0 版的日誌存放於 greengrass-root/var/log 目錄下。

對儲存體問題進行故障診斷

當本機檔案儲存空間已滿時，有些元件可能會開始故障：

  • 不會更新本機陰影。

  • 新的AWS IoT Greengrass核心 MQTT 伺服器憑證無法在本機下載。

  • 部署失敗。

您應該隨時注意本機中可用的自由空間容量。您可以根據已部署的 Lambda 函數大小、記錄組態 (請參閱日誌故障診斷) 以及本機儲存的陰影數量來計算可用空間。

訊息故障診斷

AWS IoT Greengrass 中本機傳送的所有訊息都會使用 QoS 0 傳送。在預設情況下，AWS IoT Greengrass 存放訊息於記憶體內的佇列中。因此，當 Greengrass 核心重新啟動時 (例如在群組部署或裝置重新開機後)，未處理的訊息便會遺失。但是，您可以配置AWS IoT Greengrass（v1.6 或更高版本）以將消息緩存到文件系統，以便在核心重新啟動期間保持不變。您也可以設定佇列的容量。如果您設定佇列的容量，請確定其值大於或等於 262144 位元組 (256 KB)。否則，AWS IoT Greengrass 可能不會正常啟動。如需詳細資訊，請參閱 雲端目標的 MQTT 訊息佇列。

注意

使用預設記憶體內佇列，當服務中斷最低時，我們建議您部署群組或重新啟動裝置。

您也可以設定核心以建立 AWS IoT 的持久性工作階段。這允許核心在核心離線AWS 雲端時接收從發送的消息。如需詳細資訊，請參閱 與 AWS IoT Core 的 MQTT 持久性工作階段。

陰影同步逾時問題故障診斷

若 Greengrass 核心裝置和雲端間的通訊有明顯的延遲，則陰影同步可能會因為逾時而失敗。在這種情況下，您應該會看到與以下內容相似的日誌項目：

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

可能的修復方式是設定核心裝置等待主機回應的時間。在中打開 config.json 文件，greengrass-root/config並添加一個以秒為單system.shadowSyncTimeout位的超時值的字段。例如：

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

若沒有在 config.json 中指定任何 shadowSyncTimeout 值，則預設為 5 秒鐘。

注意

對於 AWS IoT Greengrass 核心軟體 1.6 版和更新版本，預設的 shadowSyncTimeout 為 1 秒。

檢查 AWS re:Post

如果您無法使用本主題中的疑難排解資訊來解決問題，您可以在 AWSRe: post 上搜尋AWS IoT Greengrass 疑難排解或查看相關問題的AWS IoT Greengrass標籤，或張貼新問題。AWS IoT Greengrass團隊成員積極監控 AWS Re: POST。