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

AWS IoT Greengrass バージョン 1 のドキュメントを参照することができます。AWS IoT Greengrass バージョン 2 は、AWS IoT Greengrass の最新のメジャーバージョンです。AWS IoT Greengrass バージョン 2 の使用の詳細については、「AWS Greengrass V2 開発者ガイドIoT」を参照してください。

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

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

このセクションでは、AWS IoT Greengrass の問題の解決に役立つトラブルシューティング情報と考えられる解決策を示しています。

クォータ (制限) の詳細については、AWS IoT Greengrass の「 Service Quotas 」を参照してくださいアマゾン ウェブ サービス全般のリファレンス

AWS IoT Greengrass Core に関する問題

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

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

問題点

 

エラー: 設定ファイルには、CaPath、CertPath、または KeyPath がありません。[pid = <pid>] の Greengrass デーモンプロセスが終了しました。

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

  • v1.7 or later にアップグレードします。 常に最新バージョンの 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

 

エラー: /<greengrass-root>/config/config.json を解析できませんでした。

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

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

 

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

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

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

 

エラー: ランタイムの開始に失敗: ワーカーを開始できません: コンテナテストがタイムアウトしました。

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

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

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

 

エラー: ローカルの Cloudwatch で PutLogEvents の呼び出しに失敗しました、logGroup: /GreengrassSystem/connection_manager、エラー: RequestError: 送信リクエストが失敗した原因は次のとおりです。http://<path>/cloudwatch/logs/: dial tcp <address>: getsockopt: 接続が拒否されました。レスポンス: { }。

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

 

エラー: 次の理由によりサーバーを作成できません。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.

解決策: Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。AWS IoT Greengrassコアに 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 ソフトウェアが起動しない。

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

 

エラー: スプールサイズは、262144 バイト以上にする必要があります。

解決策: Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。AWS IoT Greengrassgroup.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 メッセージングエラー: メッセージを発行中にエラーが発生しました。{"errorString": "operation timed out"}

解決策: Greengrass コアが MQTT メッセージを GGCloudSpooler.log に送信できない場合に、AWS IoT Core にこのエラーが表示されることがあります。これは、コア環境の帯域幅が制限され、待ち時間が長くなる場合に発生します。v1.10.2 以降を実行している場合は、AWS IoT Greengrassconfig.jsonmqttOperationTimeout ファイルの 値を大きくしてみてください。このプロパティが存在しない場合は、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: container init が \\"rootfs_linux.go:64: \\\\/greengrass/socket/greengrass\\\\"/greengrass\\/freengrass\\\\\\/secrack\\\\////freengrass\\/\\\\/\\\\////////connectressrack-\\\\-\\\\-\\\\connect \\\\-\\\\/\\\\/\\\\/\\\\connect \\\\/\\\\connect の の の に \\\\/\\\\/\\\\/\\\\connect の の rootfrail の の の の に の の の \\\\/\\\\/\\\\connect の の \\\\/\\\\connect の の \\\\/\\\\/\\\\/\\\\/\\\\/\\\\/\\\\/\\\\ の の の は の の は rail の の は、rail の は、version

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

 

エラー: PID を使用して実行中の Greengrass デーモン: <process-id>。Some system components failed to start. Check 'runtime.log' for errors.

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

 

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

解決策: に AWS IoT GreengrassGreengrass サービスロールiot:UpdateThingShadowiot: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 に引き上げています。ユースケースに適した値を選択してください。

 

エラー: ランタイム実行エラー: Lambda コンテナ. container_linux.go:259: 開始コンテナプロセスが原因で、「process_linux.go:345: container init が \\"rootfs_linux.go:50: rootfs の準備が原因で \\\\\\"アクセス許可拒否\\\\\\"\\" が発生しました。

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

 

警告: [WARN]-[5]GK Remote: パブリックキーデータの取得エラー: ErrPrincipalNotConfigured : MqttCertificate のプライベートキーは設定されません。

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

 

エラー: ロール arn:aws:iam::<account-id>:role/<role-name> を使用して s3 url https://<region>-greengrass-updates.s3.<region>.amazonaws.com/core/<architecture>/greengrass-core-<distribution-version>.tar.gz にアクセスしようとしたときに、アクセス許可が拒否されました。

解決策: 無線 (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 アカウントの同時接続では、一意のクライアント IDs を使用する必要があります。 デフォルトでは、コアはこれらの接続にコアのモノ名をクライアント 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 \\\"

解決策: 一部のプラットフォームでは、runtime.log が AWS IoT Greengrass ファイルシステムをマウントして /proc コンテナを作成しようとしたときに、Lambda にこのエラーが表示されることがあります。または、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 greengr in over up d: failed to mask device at directory <ggc-path>: file exists"}

解決策: デプロイが失敗すると、このエラーが runtime.log に表示されることがあります。このエラーは、Lambda グループの AWS IoT Greengrass 関数がコアのファイルシステムの /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 に表示されることがあります。このエラーは、Lambda グループの AWS IoT Greengrass 関数がコアのファイルシステムの /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 関数と関連付けて、読み取り専用アクセスを許可します。

 

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

この問題を解決するには、次のいずれかを実行します。

  • Core ソフトウェア v1.9.3 以降を実行している場合は、AWS IoT Greengrassconfig.jsonsystem.useOverlayWithTmpfs プロパティを追加し、値を に設定します。true 例:

    { "system": { "useOverlayWithTmpfs": true }, "coreThing": { "caPath": "root-ca.pem", "certPath": "cloud.pem.crt", "keyPath": "cloud.pem.key", ... }, ... }
  • Raspberry Pi で AWS IoT Greengrass Core ソフトウェア v1.9.2 以前を実行している場合は、AWS IoT Greengrass Core ソフトウェア v1.9.3 以降に更新します。AWS IoT Greengrass ソフトウェアの無線更新については、「AWS IoT Greengrass Core ソフトウェアの OTA 更新」を参照してください。

  • デバイス上の Linux カーネルをアップグレードします。バージョン 4.4 以降をお勧めします。

注記

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

 

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

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

 

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

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

 

デプロイに関する問題

以下の情報は、デプロイの問題のトラブルシューティングに役立ちます。

問題点

 

現在のデプロイは機能せず、以前の正常なデプロイに戻す必要があります。

解決策: または AWS IoT コンソール API を使用して、以前の正常なデプロイを再デプロイします。AWS IoT Greengrassこれにより、対応するグループバージョンが Core デバイスにデプロイされます。

デプロイを再デプロイするには (コンソール)

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

  2. 再デプロイするデプロイが含まれている行を見つけます。[ステータス] 列で省略記号 () を選択し、[再デプロイ] を選択します。

    デプロイの [再デプロイ] アクションを示す [デプロイ] ページ。

デプロイを再デプロイするには (CLI)

  1. を使用して、再デプロイするデプロイの ID を見つけます。ListDeployments次に例を示します。

    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 に、このアカウントに関連付けられている サービスロールを引き受ける権限がありません。そうしないと、エラーが表示されます。失敗: TES サービスロールはこのアカウントに関連付けられていません。

解決策: デプロイが失敗すると、このエラーが表示される場合があります。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 公式ブログのモノのインターネットIoTの「デバイス時間を使用した サーバー証明書の検証」を参照してください。

 

エラー: 署名の検証中にエラーが発生しました。リポジトリは更新されず、以前のインデックスファイルが使用されます。GPG エラー: https://dnw9lb6lzp2d8.cloudfront.net stable InRelease: パブリックキーが使用できないため、次の署名を検証できませんでした。NO_PUBKEY 68D644ABDEXAMPLE

解決策: 用の APT リポジトリパッケージの認証に使用された信頼されたキーが見つからないか、有効期限が切れているか、無効である場合、このエラーが表示されることがあります。AWS IoT Greengrassこの問題を解決するには、キーリングパッケージをインストールします。

wget -O aws-iot-greengrass-keyring.deb https://d1onfpft10uf5o.cloudfront.net/greengrass-apt/downloads/aws-iot-greengrass-keyring.deb sudo dpkg -i aws-iot-greengrass-keyring.deb

詳細については、「apt を使用した AWS IoT Greengrass Core ソフトウェアのインストール」を参照してください。

 

デプロイが完了しない。

解決策: 次の作業を行います。

  • コアデバイスで AWS IoT Greengrass デーモンが実行されていることを確認します。コアデバイスのターミナルで、次のコマンドを実行して、 デーモンが実行されているかどうかを確認し、必要に応じてデーモンを起動します。

    1. デーモンが実行中であるかどうかを確認するには

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

      出力に root/greengrass/ggc/packages/1.11.0/bin/daemon エントリが含まれる場合、デーモンは実行されています。

      パスのバージョンは、コアデバイスにインストールされている AWS IoT Greengrass Core ソフトウェアのバージョンによって異なります。

    2. デーモンを開始するには:

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

 

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

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

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

 

デプロイが完了せず、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 デプロイエラー: クラウド {"deploymentId": ""、"errorString" にデプロイステータスをレポートできませんでした:<deployment-id> "PUT、エンドポイント: https://<deployment-status>、エラー: 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 にあります。 コアデバイス上の場所を見つけるには、crypto.caPathconfig.json プロパティを確認します。

注記

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

 

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

解決策: の所有者グループを確認します。<path> ディレクトリには、そのディレクトリに対する読み書きのアクセス許可があります。

 

次のエラーが発生する。<list-of-function-arns> are configured to run as root but Greengrass is not configured to run Lambda functions with root permissions.

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

 

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

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

 

エラー: [ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to mask greengr in over up d: failed to mask device at directory <ggc-path>: file exists"}

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

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

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

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

 

エラー: グループ <deployment-id> のタイプ NewDeployment のデプロイ <group-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 デプロイエラー: クラウド... net/http にデプロイステータスをレポートできませんでした: 接続の待機中にリクエストがキャンセルされました (Client.Timeout がヘッダーの待機中に超過しました)

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

この問題をテストするには、次のコマンドと出力を使用できます。エンドポイントの リージョン プレースホルダーを AWS リージョンに置き換えます。

$ ping greengrass-ats.iot.リージョン.amazonaws.com ping: greengrass-ats.iot.リージョン.amazonaws.com: Name or service not known
$ systemd-resolve greengrass-ats.iot.リージョン.amazonaws.com greengrass-ats.iot.リージョン.amazonaws.com: resolve call failed: DNSSEC validation failed: failed-auxiliary

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

 

エラー: arn <function-arn> を使用する関数の 'IsolationMode' 設定は無効です。

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

 

エラー: =NoContainer では、arn MemorySize を使用する関数の <function-arn> 設定は許可されません。IsolationMode

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

 

エラー: arn <function-arn> を使用した関数の Sysfs 設定へのアクセスは、IsolationMode=NoContainer では許可されません。

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

 

エラー: =GreengrassContainer には、arn MemorySize を使用した関数の <function-arn> 設定が必要です。IsolationMode

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

 

エラー: 関数 <function-arn> は、<resource-type>=NoContainer では許可されていないタイプ IsolationMode のリソースを参照します。

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

 

エラー: arn <function-arn> を使用する関数の実行設定は許可されていません。

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

 

検出の問題

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

 

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

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

 

機械学習リソースの問題

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

 

InvalidMLModelOwner - GroupOwnerSetting は ML モデルリソースに提供されていますが、GroupOwner または GroupPermission がありません

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

 

NoContainer 関数は、機械学習リソースをアタッチするときにアクセス権限を設定できません。<function-arn> は、リソースアクセスポリシーでアクセス権限 <ro/rw> を持つ機械学習リソース <resource-id> を参照します。

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

 

関数 <function-arn> は、ResourceAccessPolicy と resource OwnerSetting の両方でアクセス権限がない機械学習リソース <resource-id> を参照します。

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

 

関数 <function-arn> は、権限 \「rw\」の機械学習リソース <resource-id> を参照し、リソース所有者設定 GroupPermission は \「ro\」のみを許可します。

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

 

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

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

 

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

解決策 : 同じ OS グループが Lambda 関数の ID として実行、および機械学習リソースのリソース所有者として指定されているが、リソースが 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 Microsoft Windows の場合AWS Command Line Interface ユーザーガイド.

 

警告 IPv4 は無効になっています。ネットワークは機能しません。

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

 

エラー ファイアウォールは、Windowsとコンテナ間のファイル共有をブロックしています。

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

 

エラー GetAuthorizationToken 操作の呼び出し中にエラーが発生しました (AccessDeniedException)。ユーザー: arn:aws:iam::<account-id>:user/<user-name> は、次の実行権限がありません: ecr:GetAuthorizationToken on resource:*

このエラーは、 aws ecr get-login-password コマンドで、 にアクセスするのに十分な権限がない場合、 Amazon ECR リポジトリです。詳細については、以下を参照してください。 Amazon ECR リポジトリ ポリシーの例 および アクセスする Amazon ECR リポジトリAmazon ECR ユーザーガイド.

 

エラー: サービス greengrass のコンテナを作成できない: Conflict. The container name "/aws-iot-greengrass" is already in use.

解決策: これは、古いコンテナでコンテナ名が使用されている場合に表示される場合があります。この問題を解決するには、以下のコマンドを実行して古い 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 がクラッシュするため手動で再起動する必要があります。

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

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

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

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

Greengrass グループのログ設定を構成できます。ログを CloudWatch Logs 送信する、ログをローカルファイルシステムに保存する、またはその両方などです。問題のトラブルシューティングを行う場合に詳細情報を取得するには、ログレベルを一時的に 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/user/

ユーザー定義 Lambda 関数のすべてのログが含まれています。このフォルダを確認して、ローカル Lambda 関数のエラーメッセージを検索します。

注記

デフォルトでは、greengrass-root/greengrass ディレクトリです。書き込みディレクトリが設定されている場合には、ログはこのディレクトリにあります。

ログの保存先としてクラウドを設定している場合は、CloudWatch Logs を使用してログメッセージを確認します。crash.log は、AWS IoT Greengrass コア デバイスのファイルシステムログでのみ見つかります。

ログを CloudWatch に書き込むように AWS IoT を設定している場合、システムコンポーネントが 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 0 で送信されます。QoSデフォルトでは、AWS IoT Greengrass はメッセージをメモリ内のキューに保存します。したがって、グループのデプロイ後やデバイスの再起動後などに Greengrass コアを再起動すると、未処理のメッセージは失われます。ただし、AWS IoT Greengrass (v1.6 or later) を設定してファイルシステムにメッセージをキャッシュして、コアの再起動でも保持されるようにできます。また、キューサイズを設定することもできます。キューサイズを設定する場合、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.jsonshadowSyncTimeout 値を指定しない場合は、デフォルト値の 5 秒が使用されます。

注記

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

AWS IoT Greengrass フォーラムを確認します。

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