AWS IoT Greengrass のトラブルシューティング - AWS IoT Greengrass

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 quotas (制限) の詳細については、「Amazon Web Services 全般のリファレンス」の「Service Quotas」を参照してください。

AWS IoT Greengrass Core に関する問題

AWS IoT Greengrass Core ソフトウェアが起動しない場合は、以下の一般的なトラブルシューティング手順を試してください。

以下の症状とエラーを検索して、AWS IoT Greengrass コアの問題のトラブルシューティングに役立つ情報を見つけます。

問題

 

エラー: 設定ファイルに CaPath、、 CertPath または がありません KeyPath。The Greengrass daemon process with [pid = <pid>] died。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、crash.log でこのエラーが表示されることがあります。このエラーが発生する場合、v1.6 以前を実行している可能性があります。次のいずれかを行います:

  • v1.7 以降にアップグレード。常に最新バージョンの AWS IoT Greengrass Core ソフトウェアを実行することをお勧めします。ダウンロード情報については、「AWS IoT Greengrass Core ソフトウェア」を参照してください。

  • AWS IoT Greengrass Core ソフトウェアバージョンに正しい config.json 形式を使用します。詳細については、「AWS IoT Greengrass Core 設定ファイル」を参照してください。

    注記

    コアデバイスにインストールされている AWS IoT Greengrass Core ソフトウェアのバージョンを確認するには、ターミナルデバイスで次のコマンドを実行します。

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

 

次のエラーが発生する。Failed to parse /<greengrass-root>/config/config.json。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。Greengrass 設定ファイルが有効な JSON 形式であることを確認します。

config.json (/greengrass-root/config から) を開き、JSON 形式を検証します。例えば、カンマが正しく使用されていることを確認してください。

 

エラー: TLS 設定の生成中にエラーが発生しました: ErrUnknownURIScheme

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。Greengrass 設定ファイルの crypto セクションのプロパティが有効であることを確認します。エラーメッセージに詳細が説明されています。

config.json (/greengrass-root/config にある) を開き、crypto セクションを確認します。例えば、証明書とキーのパスは正しい URI 形式を使用し、正しい場所を参照している必要があります。

 

次のエラーが発生する。Runtime failed to start: unable to start workers: container test timed out。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。Greengrass 設定ファイルpostStartHealthCheckTimeout プロパティを設定します。このオプションのプロパティは、ヘルスチェックが開始してから終了するまで Greengrass デーモンが待機する時間 (ミリ秒単位) を設定します。デフォルト値は 30 秒 (30000 ミリ秒) です。

config.json (/greengrass-root/config から) を開きます。runtime オブジェクトで postStartHealthCheckTimeout プロパティを追加し、30,000 を超える値を設定します。有効な JSON ドキュメントを作成するために必要な場所にカンマを追加します。例:

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

 

エラー: PutLogEventsローカル Cloudwatch、logGroup : /GreengrassSystem/connection_manager、エラー: RequestError: Post http://<path>/cloudwatch/logs/: dial tcp <address>: getockopt: connection deniedd、response: { } が原因でリクエストの送信に失敗しました。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。このエラーが発生する場合、Raspberry Pi で AWS IoT Greengrass を実行していて、必要なメモリの設定が完了していない可能性があります。詳細については、このステップを参照してください。

 

次のエラーが発生する。Unable to create server due to: failed to load group: chmod /<greengrass-root>/ggc/deployment/lambda/arn:aws:lambda:<region>:<account-id>:function:<function-name>:<version>/<file-name>: no such file or directory。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。コアに Lambda 実行可能ファイル をデプロイしたら、関数の Handler プロパティを group.json ファイル (/greengrass-root/ggc/deployment/group にある) で確認します。ハンドラがコンパイルした実行可能ファイルの正確な名前でない場合、group.json ファイルのコンテンツを空の JSON オブジェクト ({}) に置き換え、以下のコマンドを実行して AWS IoT Greengrass を開始します。

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

次に、AWS Lambda API を使用して関数設定の handler パラメータを更新し、新しい関数バージョンを発行してエイリアスを更新します。詳細については、「AWS Lambda 関数のバージョニングとエイリアス」を参照してください。

Greengrass グループにエイリアスで関数を追加したと想定すると (推奨)、これでグループを再デプロイできるようになります。(そうでない場合は、グループをデプロイする前に、グループ定義とサブスクリプションで新しい関数バージョンあるいはエイリアスを指定する必要があります。)

 

コンテナ化なしの実行から Greengrass コンテナでの実行に変更した後、AWS IoT Greengrass Core ソフトウェアが起動しない。

解決策: コンテナの依存関係が失われていないことを確認します。

 

次のエラーが発生する。Spool size should be at least 262144 bytes。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。group.json ファイル (/greengrass-root/ggc/deployment/group にある) を開き、このファイルの内容を空の JSON オブジェクト ({}) に置き換え、以下のコマンドを実行して AWS IoT Greengrass を起動します。

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

次に、「ローカルストレージでメッセージをキャッシュするには」のステップに従います。GGCloudSpooler 関数で、GG_CONFIG_MAX_SIZE_BYTES 値が 262144 以上に指定されていることを確認します。

 

次のエラーが発生する。[ERROR]-Cloud messaging error: Error occurred while trying to publish a message. {"errorString": "operation timed out"}

解決策: 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: starting container process caused "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\\\"\""。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、runtime.log でこのエラーが表示されることがあります。このエラーは、umask0022 よりも高い場合に発生します。この問題を解決するには、umask0022 以下に設定する必要があります。値 0022 では、デフォルトで新しいファイルに対する読み取りアクセス許可がすべてのユーザーに付与されます。

 

次のエラーが発生する。Greengrass daemon running with PID: <process-id>。Some system components failed to start。Check 'runtime.log' for errors。

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。特定のエラー情報については、runtime.logcrash.log を確認してください。詳細については、「ログでのトラブルシューティング」を参照してください。

 

デバイスのシャドウがクラウドと同期していない。

解決策: Greengrass サービスロールで AWS IoT Greengrass に iot:UpdateThingShadow および iot:GetThingShadow アクションへのアクセス許可があることを確認します。サービスロールで AWSGreengrassResourceAccessRolePolicy 管理ポリシーを使用している場合は、これらのアクセス許可はデフォルトで含まれています。

シャドウ同期タイムアウト問題のトラブルシューティング を参照してください。

 

次のエラーが発生する。unable to accept TCP connection. accept tcp [::]:8000: accept4: too many open files。

解決策: greengrassd スクリプト出力でこのエラーが表示されることがあります。このエラーが発生する場合、AWS IoT Greengrass Core ソフトウェアのファイル記述子の制限がしきい値に達している可能性があります。その制限を引き上げる必要があります。

以下のコマンドを使用して AWS IoT Greengrass Core ソフトウェアを再起動します。

ulimit -n 2048
注記

この例では、制限を 2048 に引き上げています。ユースケースに適した値を選択してください。

 

次のエラーが発生する。Runtime execution error: unable to start lambda container. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:50: preparing rootfs caused \\\"permission denied\\\"\""。

解決策: ルートディレクトリの直下に AWS IoT Greengrass をインストールするか、AWS IoT Greengrass Core ソフトウェアがインストールされているディレクトリとその親ディレクトリに対する execute アクセス許可がすべてのユーザーに付与されていることを確認します。

 

警告: [WARN]-[5]GK リモート: パブリックキーデータの取得中にエラーが発生しました: ErrPrincipalNotConfigured: のプライベートキー MqttCertificate が設定されていません。

解決策: AWS IoT Greengrass は一般的なハンドラを使用してすべてのセキュリティプリンシパルのプロパティを検証します。runtime.log でのこの警告は、ローカル MQTT サーバー用のカスタムプライベートキーを指定した場合を除き、予期されるものです。詳細については、「AWS IoT Greengrass コアセキュリティプリンシパル」を参照してください。

 

次のエラーが発生する。Permission denied when attempting to use role arn:aws:iam::<account-id>:role/<role-name> to access s3 url https://<region>-greengrass-updates.s3.<region>.amazonaws.com/core/<architecture>/greengrass-core-<distribution-version>.tar.gz

解決策: over-the-air (OTA) の更新が失敗すると、このエラーが表示されることがあります。署名者ロールポリシーで、ターゲット AWS リージョンを Resource として追加します。この署名者ロールは、AWS IoT Greengrass ソフトウェア更新の S3 URL の事前署名に使用されます。詳細については、「S3 URL の署名者ロール」を参照してください。

 

AWS IoT Greengrass コアは、ネットワークプロキシを使用するように設定されていて、Lambda 関数は送信接続を行うことができません。

解決策: 接続を行うために Lambda 関数で使用されるランタイムと実行可能ファイルによっては、接続タイムアウトのエラーも発生することがあります。Lambda 関数が適切なプロキシ設定を使用して、ネットワークプロキシ経由で接続することを確認します。AWS IoT Greengrass は、http_proxyhttps_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

 

次のエラーが発生する。unable to start lambda container. container_linux.go:259: starting container process caused "process_linux.go:345: container init caused \"rootfs_linux.go:62: mounting \\\"proc\\\" to rootfs \\\"

解決策: プラットフォームによっては、AWS IoT Greengrass が /proc ファイルシステムをマウントして Lambda コンテナを作成しようとすると、runtime.log でこのエラーが表示されることがあります。または、operation not permittedEPERM などの同様のエラーが表示される場合があります。これらのエラーは、依存関係チェッカーのスクリプトパスによってプラットフォーム上でテストが実行された場合でも発生する可能性があります。

以下のいずれかの解決策を試してください。

  • Linux カーネルで CONFIG_DEVPTS_MULTIPLE_INSTANCES オプションを有効にします。

  • ホストの /proc マウントオプションを rw,relatim のみに設定します。

  • Linux カーネルを 4.9 以降にアップグレードします。

注記

この問題は、ローカルリソースアクセスの /proc マウントに関連していません。

 

[ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to mask greengrass root in overlay upper dir: failed to create mask device at directory <ggc-path>: file exists"}

解決策: デプロイに失敗した場合に、runtime.log でこのエラーが表示されることがあります。このエラーは、AWS IoT Greengrass グループの Lambda 関数がコアのファイルシステム内の /usr ディレクトリにアクセスできない場合に発生します。

この問題を解決するには、ローカルボリュームリソースをグループに追加し、グループをデプロイします。このリソースは次の条件を満たす必要があります。

  • /usr を [Source path (ソースパス)] および [Destination path (送信先パス)] として指定します。

  • リソースを所有する Linux グループの OS グループアクセス許可を自動的に追加する

  • Lambda 関数と関連付けて、読み取り専用アクセスを許可します。

 

[ERROR]-Deployment failed. {"deploymentId": "<deployment-id>", "errorString": "container test process with pid <pid> failed: container process state: exit status 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 を [Source path (ソースパス)] および [Destination path (送信先パス)] として指定します。

  • リソースを所有する Linux グループの OS グループアクセス許可を自動的に追加する

  • Lambda 関数と関連付けて、読み取り専用アクセスを許可します。

 

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、runtime.log ファイルにこのエラーが表示されることがあります。この問題は、Debian オペレーティングシステムで生じやすい問題です。

この問題を解決するには、次の操作を行います。

  1. AWS IoT Greengrass Core ソフトウェアを v1.9.3 以降にアップグレードします。これにより、この問題は自動的に解決されます。

  2. AWS IoT Greengrass Core ソフトウェアをアップグレードしてもこのエラーが発生する場合は、config.json ファイルで system.useOverlayWithTmpfs プロパティを true に設定してください。

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

AWS IoT Greengrass コアソフトウェアバージョンがエラーメッセージに表示されます。Linux カーネルのバージョンを確認するには、uname -r を実行します。

 

エラー: [DEBUG] - ルートの取得に失敗しました。メッセージを破棄します。

解決策: グループのサブスクリプションを確認し、[DEBUG] メッセージにリストされているサブスクリプションが存在することを確認します。

 

エラー: [Errno 24] 開いている <lambda-function> が多すぎます,[Errno 24] 開いているファイルが多すぎます

解決策: Lamda 関数が関数ハンドラ内の StreamManagerClient をインスタンス化する場合、この関数のログファイルにこのエラーが表示されます。ハンドラの外部にクライアントを作成することをお勧めします。詳細については、「ストリームを操作するために StreamManagerClient を使用する」を参照してください。

 

次のエラーが発生する:ds server failed to start listening to socket: listen unix <ggc-path>/ggc/socket/greengrass_ipc.sock: bind: invalid argument

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。このエラーは、AWS IoT Greengrass Core ソフトウェアが長いファイルパスを持つフォルダにインストールされると発生します。AWS IoT Greengrass Core ソフトウェアは、書き込みディレクトリを使用しない場合は 79 バイト未満、書き込みディレクトリを使用する場合は 83 バイトのファイルパスを持つフォルダに再インストールしてください。

[INFO] (Copier) aws.greengrass.StreamManager: stdout。原因: com.fasterxml.jackson.databind.JsonMappingException: Instant exceeds minimum or maximum instant

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}

使用している AWS IoT Greengrass コアソフトウェアのバージョンが v1.11.3 より古く、それ以降のバージョンにアップグレードする場合は、OTA アップデートを使用して v1.11.4 にアップグレードします。

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

AWS IoT Greengrass コアソフトウェアを APT リポジトリからインストールしたデバイスで apt update を実行する場合、次のエラーが表示される可能性があります。

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 を使用して、以前の正常なデプロイを再デプロイします。これにより、対応するグループバージョンが Core デバイスにデプロイされます。

デプロイを再デプロイするには (コンソール)
  1. グループの設定ページで、[Deployments] (デプロイ) を選択します。このページには、日付と時刻、グループバージョン、各デプロイ試行のステータスなど、グループのデプロイ履歴が表示されます。

  2. 再デプロイするデプロイが含まれている行を見つけます。再デプロイするデプロイを選択し、[Redeploy] (再デプロイ) を選択します。

    デプロイの [再デプロイ] アクションを示す [デプロイ] ページ。
デプロイを再デプロイするには (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 エラーがログに表示される。

解決策: クラウドの AWS IoT Greengrass コアのポリシーに、許可されたアクションとして "greengrass:*" が含まれていることを確認します。

 

create-deployment コマンドを初めて実行すると、 ConcurrentDeployment エラーが発生します。

解決策: デプロイが進行中である可能性があります。get-deployment-status を実行してデプロイが作成済みかどうかを確認できます。作成済みでない場合は、デプロイを作成し直します。

 

次のエラーが発生する。Greengrass is not authorized to assume the Service Role associated with this account, or the error: Failed: TES service role is not associated with this account。

解決策: デプロイに失敗した場合に、このエラーが表示されることがあります。Greengrass サービスロールが、現在の AWS リージョンの AWS アカウントに関連付けられていることを確認します。詳細については、Greengrass サービスロールの管理 (CLI)またはGreengrass サービスロールの管理 (コンソール)を参照してください。

 

エラー: デプロイのダウンロードステップを実行できません。ダウンロード中のエラー: グループ定義ファイルのダウンロード中のエラー: ... x509: 証明書の有効期限が切れているか、まだ有効ではありません

解決策: デプロイに失敗した場合に、runtime.log でこのエラーが表示されることがあります。x509: certificate has expired or is not yet valid というメッセージが含まれた Deployment failed エラーが表示された場合は、デバイスのクロックを確認してください。TLS 証明書と X.509 証明書は、IoT システムを構築するための安全な基盤を提供しますが、サーバーとクライアントでの正確な時間を必要とします。IoT デバイスは、サーバー証明書を使用する AWS IoT Greengrass や他の TLS サービスへの接続を試行する前に、正しい時間 (15 分以内) を必要とします。詳細については、「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 Core ソフトウェアのバージョンによって異なります。

    2. 次のようにしてデーモンを開始します。

      cd /greengrass/ggc/core/ sudo ./greengrassd start
  • Core デバイスが接続され Core 接続エンドポイントが適切に設定されていることを確認します。

 

エラー: java または java8 実行可能ファイルが見つかりません。または、エラー: NewDeployment グループ <group-id> のタイプのデプロイ <deployment-id> に失敗しましたエラー: <worker-id> のワーカーが初期化に失敗した理由: インストール済み Java バージョンが 8 以上である必要があります

解決策: AWS IoT Greengrass コアでストリームマネージャーが有効になっている場合は、グループをデプロイする前に、コアデバイスに Java 8 ランタイムをインストールする必要があります。詳細については、ストリームマネージャーの要件を参照してください。AWS IoT コンソールの [Default Group creation] (デフォルトのグループ作成) ワークフローを使用してグループを作成する場合、ストリームマネージャーはデフォルトで有効になります。

または、ストリームマネージャーを無効にしてから、グループをデプロイします。詳細については、「ストリームマネージャーの設定 (コンソール)」を参照してください。

 

デプロイが完了せず、runtime.log に複数の「wait 1s for container to stop」エントリが含まれる。

解決策: コアデバイスのターミナルで以下のコマンドを実行して、AWS IoT Greengrass デーモンを再起動します。

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

 

デプロイが完了せず、runtime.log に "[ERROR]-Greengrass deployment error: failed to report deployment status back to 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"}" が含まれる

解決策: Greengrass コアが HTTPS プロキシ接続を使用するように設定されていて、プロキシサーバーの証明書チェーンがシステムで信頼されていない場合に、runtime.log にこのエラーが表示されることがあります。この問題を解決するには、ルート CA 証明書に証明書チェーンを追加します。Greengrass コアは、AWS IoT Greengrass との HTTPS および MQTT 接続で TLS 認証に使用される証明書プールに、このファイルの証明書を追加します。

次の例は、ルート CA 証明書ファイルに追加されたプロキシサーバー 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.jsoncrypto.caPath のプロパティを確認します。

注記

greengrass-root は、デバイスで AWS IoT Greengrass Core ソフトウェアがインストールされているパスを表します。通常、これは /greengrass ディレクトリです。

 

エラー: NewDeployment グループ <group-id> の タイプのデプロイ <deployment-id> がエラー: 処理中にエラーが発生しました。グループ設定が無効です: 112 または [119 0] にファイル <path> に対する rw アクセス許可がありません。

解決策: <path> ディレクトリの所有者グループに、そのディレクトリに対する読み書きアクセス許可が付与されていることを確認します。

 

エラー: <list-of-function-arns> は root として実行するように設定されていますが、Greengrass は root 権限を持つ Lambda 関数を実行するように設定されていません。

解決策: デプロイに失敗した場合に、runtime.log でこのエラーが表示されることがあります。Lambda 関数に root アクセス許可での実行を許可するように AWS IoT Greengrass を設定していることを確認します。greengrass_root/config/config.jsonallowFunctionsToRunAsRoot の値を yes に変更するか、別のユーザー/グループとして実行するように Lambda 関数を変更します。詳細については、「root としての Lambda 関数の実行」を参照してください。

 

エラー: NewDeployment グループ <group-id> の タイプのデプロイ <deployment-id> に失敗しました: Greengrass デプロイエラー: デプロイでダウンロードステップを実行できませんでした。エラー: ダウンロードされたグループファイルをロードできませんでした: ユーザー名に基づいて UID が見つかりませんでした: userName ggc_user: user: unknown user ggc_user。

解決策: AWS IoT Greengrass グループのデフォルトのアクセス ID が標準のシステムアカウントを使用する場合、ggc_user ユーザーと ggc_group グループがデバイスに存在する必要があります。ユーザーとグループを追加する方法については、このステップを参照してください。表示されているとおりに正確に名前を入力してください。

 

次のエラーが発生する。[ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to mask greengrass root in overlay upper dir: failed to create mask device at directory <ggc-path>: file exists"}

解決策: デプロイに失敗した場合に、runtime.log でこのエラーが表示されることがあります。このエラーは、Greengrass グループの Lambda 関数がコアのファイルシステム内の /usr ディレクトリにアクセスできない場合に発生します。この問題を解決するには、ローカルボリュームリソースをグループに追加し、グループをデプロイします。リソースは次の条件を満たす必要があります。

  • /usr を [Source path (ソースパス)] および [Destination path (送信先パス)] として指定します。

  • リソースを所有する Linux グループの OS グループアクセス許可を自動的に追加する

  • Lambda 関数と関連付けて、読み取り専用アクセスを許可します。

 

エラー: NewDeployment グループ <group-id> の タイプのデプロイ <deployment-id> に失敗しました: プロセスの開始に失敗しました: container_linux.go:259: コンテナプロセスの開始中に「process_linux.go:250: init の exec setns プロセスの実行中に \"wait: no child processes\"」が発生しました。

解決策: デプロイに失敗した場合に、このエラーが表示されることがあります。デプロイを再試行します。

 

次のエラーが発生する。[WARN]-MQTT[client] dial tcp: lookup <host-prefix>-ats.iot.<region>.amazonaws.com: no such host ..。[ERROR]-Greengrass deployment error: failed to report deployment status back to cloud ... net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

解決策: systemd-resolved を使用している場合にこのエラーが表示されることがあります。これにより、デフォルトで DNSSEC 設定が有効になります。その結果、多くのパブリックドメインは認識されません。AWS IoT Greengrass エンドポイントに到達しようとするとホストが見つからないため、デプロイは In Progress 状態のままです。

この問題をテストするには、次のコマンドと出力を使用できます。エンドポイントの region プレースホルダーを 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

考えられる解決策の 1 つは、DNSSEC を無効にすることです。DNSSECfalse の場合、DNS ルックアップは 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-versionDefaultConfigIsolationMode 値がサポートされていない場合です。サポートされている値は、GreengrassContainer および NoContainer です。

 

エラー: arn <function-arn> を持つ関数のIsolationMode「」設定が無効です。

解決策: このエラーが発生するのは、function-definition-version の <function-arn> で IsolationMode 値がサポートされていない場合です。サポートされている値は、GreengrassContainer および NoContainer です。

 

エラー: MemorySize arn <function-arn> を持つ関数の設定は、 IsolationMode= では許可されていませんNoContainer。

解決策: このエラーは、MemorySize 値を設定したときに、コンテナ化を使用せずに実行することを選択した場合に発生します。コンテナ化を使用せずに実行される Lambda 関数には、メモリ制限を設定することができません。制限を削除するか、AWS IoT Greengrass コンテナで実行するように Lambda 関数を変更できます。

 

エラー: IsolationMode= では、arn <function-arn> を持つ関数の Sysfs 設定にアクセスすることはできませんNoContainer。

解決策: このエラーは、AccessSysfstrue を指定したときに、コンテナ化を使用せずに実行することを選択した場合です。コンテナ化を使用せずに実行する Lambda 関数は、ファイルシステムに直接アクセスできるようにコードを更新する必要があり、AccessSysfs を使用することはできません。AccessSysfs で値として false を指定するか、AWS IoT Greengrass コンテナで実行するように Lambda 関数を変更できます。

 

エラー: MemorySize IsolationMode= には arn <function-arn> を持つ関数の設定が必要ですGreengrassContainer。

解決策: このエラーが発生するのは、AWS IoT Greengrass コンテナで実行している Lambda 関数に MemorySize の制限を指定しなかったためです。エラーを解決するには MemorySize の値を指定します。

 

エラー: Function <function-arn> は、 IsolationMode= で許可されていない <resource-type> 型のリソースを指しますNoContainer。

解決策: コンテナ化を使用せずに Lambda 関数を実行する場合は、Local.DeviceLocal.VolumeML_Model.SageMaker.JobML_Model.S3_Object または S3_Object.Generic_Archive リソースタイプにアクセスできません。これらのリソースタイプが必要な場合は、AWS IoT Greengrass コンテナで実行する必要があります。コンテナ化を使用しないで実行する場合は、Lambda 関数のコードを変更して、ローカルデバイスに直接アクセスすることもできます。

 

次のエラーが発生する。Execution configuration for function with arn <function-arn> is not allowed。

解決策: このエラーが発生するのは、GGIPDetector または GGCloudSpooler を使用してシステムの Lambda 関数を作成し、IsolationMode または RunAs 設定を指定した場合です。このシステムの Lambda 関数から Execution パラメータを削除する必要があります。

 

検出の問題

AWS IoT Greengrass Discovery Service の問題のトラブルシューティングには、以下の情報が役立ちます。

 

エラー: デバイスがメンバーになっているグループの数が多すぎます。デバイスを 10 個を超えるグループに含めることはできません。

解決策: これは既知の制限です。クライアントデバイスは、最大 10 個のグループのメンバーにすることができます。

 

機械学習リソースの問題

次の情報を使用して、機械学習リソースの問題のトラブルシューティングに役立ててください。

 

InvalidMLModelOwner - GroupOwnerSetting ML モデルリソースで提供されますが、 GroupOwner または GroupPermission は存在しません

解決策: 機械学習リソースに ResourceDownloadOwnerSetting オブジェクトが含まれているが、必須の GroupOwnerまたは GroupPermissionプロパティが定義されていない場合、このエラーが表示されます。この問題を解決するには、不足しているプロパティを定義します。

 

NoContainer 関数は、 Machine Learning リソースをアタッチするときにアクセス許可を設定できません。<function-arn> は、リソースアクセスポリシーでアクセス許可 <ro/rw> を持つ Machine Learnin リソース <resource-id> を指します。

解決策: コンテナ化されていない Lambda 関数が機械学習リソースに対する関数レベルのアクセス権限を指定した場合、このエラーが表示されます。コンテナ化されていない関数は、機械学習リソースに定義されているリソース所有者のアクセス権限からアクセス権限を継承する必要があります。この問題を解決するには、コンソールから [inherit resource owner permissions] (リソース所有者のアクセス許可を継承する) を選択するか、API を使用して Lambda 関数のリソースアクセスポリシーからアクセス権限を削除するかを選択します。

 

関数 <function-arn> は、 ResourceAccessPolicy と の両方のリソースに不足しているアクセス許可を持つ Machine Learning リソース <resource-id> を指します OwnerSetting。

解決策: このエラーは、機械学習リソースへのアクセス権限が、アタッチされた Lambda 関数またはリソースに対して設定されていない場合に表示されます。この問題を解決するには、Lambda 関数の ResourceAccessPolicyプロパティまたは リソースの OwnerSettingプロパティでアクセス許可を設定します。

 

関数 <function-arn> はMachine Learningリソース <resource-id> を \"rw\" 許可で参照しますが、リソース所有者設定 GroupPermissionでは \"ro\" のみ許可します。

解決策: このエラーは、アタッチされた Lambda 関数に定義されたアクセス権限が、機械学習リソースに対して定義されたリソース所有者のアクセス権限を超えた場合に表示されます。この問題を解決するには、Lambda 関数に対して制限のより厳しいアクセス権限を設定するか、リソース所有者の制限がより低いアクセス権限を設定します。

 

NoContainer 関数 <function-arn> は、ネストされた送信先パスのリソースを指します。

解決策: コンテナ化されていない Lambda 関数にアタッチされた複数の機械学習リソースが同じ送信先パスまたはネストされた送信先パスを使用している場合に、このエラーが表示されます。この問題を解決するには、リソースに別の送信先パスを指定します。

 

Lambda <function-arn> は、同じグループ所有者 ID を共有することでリソース <resource-id> にアクセスします。

解決策: このエラーは、Lambda 関数の実行者 ID と、機械学習リソースのリソース所有者に同じ OS グループを指定しながら、リソースが Lambda 関数にアタッチされていない場合に runtime.log に記録されます。この設定では、Lambda 関数に暗黙のアクセス権限が付与されます。このアクセス権限は、AWS IoT Greengrass の認証なしでリソースにアクセスするために使用できます。

この問題を解決するには、プロパティの 1 つに別の OS グループを使用するか、機械学習リソースを Lambda 関数にアタッチします。

Docker での AWS IoT Greengrass Core に関する問題

以下の情報は、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 ユーザーガイド」の「Installing the AWS Command Line Interface on Microsoft Windows 」(Microsoft Windows に - をインストールする) を参照してください。

 

次の警告が表示される。IPv4 is disabled。ネットワークは機能しません。

解決策: Linux コンピュータで AWS IoT Greengrass を実行すると、この警告または類似のメッセージが表示されることがあります。このステップで説明しているように、IPv4 ネットワーク転送を有効にします。IPv4 転送が有効ではない場合、AWS IoT Greengrass クラウドデプロイと MQTT 通信は機能しません。詳細については、Docker ドキュメントの「Configure namespaced kernel parameters (sysctls) at runtime」を参照してください。

 

エラー: A firewall is blocking file Sharing between windows and the containers. (ファイアウォールが、ウィンドウとコンテナー間のファイル共有をブロックしています。)

解決策: Windows コンピュータで Docker を実行すると、このエラーまたは Firewall Detected メッセージが表示されることがあります。このエラーは、仮想プライベートネットワーク (VPN) にサインインしているときにも発生する場合があり、ネットワーク設定が原因で共有ドライブをマウントできないことがあります。このような場合は、VPN をオフにし、Docker コンテナを再実行します。

 

エラー: GetAuthorizationToken オペレーションの呼び出し時にエラー (AccessDeniedException) が発生しました: User: arn:aws:iam::<account-id>:user/<user-name> is not authorized to perform: ecr:GetAuthorizationToken on resource: *

このエラーは、Amazon ECR リポジトリにアクセスするための十分な権限がない状態で aws ecr get-login-password コマンドを実行したときに表示されることがあります。詳細については、「Amazon ECR ユーザーガイド」の「Amazon ECR Repository Policy Examples」(Amazon ECR リポジトリポリシーの例) および「1 つの Amazon ECR リポジトリにアクセスする」を参照してください。

 

次のエラーが発生する。Cannot create container for the service greengrass: Conflict。コンテナ名「/aws-iot-greengrass」は既に使用されています。

解決策: このエラーが発生する場合は、そのコンテナ名が古いコンテナで使用されている可能性があります。この問題を解決するには、以下のコマンドを実行して古い Docker コンテナを削除します。

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

 

次のエラーが発生する。[FATAL]-Failed to reset thread's mount namespace due to an unexpected error: "operation not permitted"。整合性を維持するには、GGC がクラッシュするため手動で再起動する必要があります。

解決策: このエラーが runtime.log で表示される場合、GreengrassContainer Lambda 関数を、Docker コンテナで実行されている AWS IoT Greengrass コアにデプロイしようとしている可能性があります。現在、Greengrass Docker コンテナにデプロイできるのは、NoContainer Lambda 関数のみです。

この問題を解決するには、Lambda 関数がすべて、NoContainer モードであることを確認し、新しいデプロイを開始します。次に、コンテナを起動する際、既存の deployment ディレクトリを AWS IoT Greengrass コアの Docker コンテナにバインドマウントしないでください。代わりに、空の deployment ディレクトリを所定の場所に作成して、Docker コンテナでそのディレクトリをバインドマウントします。これにより、新しい Docker コンテナは、NoContainer モードで実行されている Lambda 関数を備えた最新のデプロイを受け取ることができます。

詳細については、「Docker コンテナでの AWS IoT Greengrass の実行」を参照してください。

ログでのトラブルシューティング

ログを Logs に送信するか、ローカルファイルシステムにログを保存するか、またはその両方にログを保存するかなど、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 ログの CloudWatch Logs へのアップロードを処理するAWS IoT Greengrassコンポーネントのログが含まれます。で 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 Core ソフトウェア v1.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 []}"

解決方法としては、コアデバイスでホストのレスポンスを待機する時間を設定します。greengrass-root/configconfig.json ファイルを開き、タイムアウトの値を秒単位で指定する system.shadowSyncTimeout フィールドを追加します。例:

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

config.jsonshadowSyncTimeout 値を指定しない場合は、デフォルト値の 5 秒が使用されます。

注記

AWS IoT Greengrass Core ソフトウェア v1.6 以前では、デフォルトの shadowSyncTimeout は 1 秒です。

AWS re:Post を確認する

このトピックのトラブルシューティング情報を使用しても問題を解決できない場合は、AWS IoT Greengrass のトラブルシューティング を検索するか、AWS re:Post の AWS IoT Greengrass タグで関連する問題を確認し、新しい質問を投稿してください。AWS IoT Greengrass チームのメンバーは、AWS re:Post をアクティブにモニタリングします。