AWS IoT Greengrass
開発者ガイド

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

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

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

AWS IoT Greengrass Core に関する問題

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

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

トピック

 

次のエラーが発生する。The configuration file is missing the CaPath, CertPath or KeyPath.The Greengrass daemon process with [pid = <pid>] died.

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

 

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

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

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

 

次のエラーが発生する。Error occurred while generating TLS config: 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 }, ...

 

次のエラーが発生する。Failed to invoke PutLogEvents on local Cloudwatch, logGroup: /GreengrassSystem/connection_manager, error: RequestError: send request failed caused by: Post http://<path>/cloudwatch/logs/: dial tcp <address>: getsockopt: connection refused, response: { }.

解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。このエラーが発生する場合、Raspbian Stretch OS を搭載した 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 以上に指定されていることを確認します。

 

次のエラーが発生する。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 を確認してください。詳細については、「ログでのトラブルシューティング」を参照してください。

 

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

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

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

 

ユーザーの名前空間が有効になっていないために AWS IoT Greengrass Core ソフトウェアが Raspberry Pi で実行されない。

解決策: この解決策は Jessie Raspbian ディストリビューションにのみ適用されます。他のディストリビューションではこのコマンドを実行しないでください。Stretch(以降)ディストリビューションでは、デフォルトでユーザー名前空間が有効になっています。

Jessie デバイスで BRANCH=stable rpi-update を実行して、ファームウェアおよび kernel を最新の安定したバージョンに更新します。

注記

AWS IoT Greengrass をデフォルトの Greengrass container モードで実行するには、ユーザー名前空間のサポートが必要です。No container モードの実行では必要ありません。詳細については、「Lambda 関数のコンテナ化を選択する場合の考慮事項」を参照してください。

 

次のエラーが発生する。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 Remote: Error retrieving public key data: ErrPrincipalNotConfigured: private key for MqttCertificate is not set.

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

 

次のエラーが発生する。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.

解決策: 無線 (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'])

注記

接続を行うために使用されるほとんどの共通ライブラリ (boto3 や cURL など、および python requests パッケージ) は、デフォルトでこれらの環境変数を使用します。

 

このコアは、無限の接続 - 切断ループにあります。runtime.log ファイルには、継続的な一連の接続と切断のエントリが含まれています。

解決策: このエラーは、AWS IoT への MQTT 接続用に別のデバイスがクライアント ID をコアのモノ名を使用するようにハードコードされている場合に発生します。同じ AWS リージョンと AWS アカウントの同時接続では、一意のクライアント ID を使用する必要があります。デフォルトでは、コアは上記の接続にコアのモノ名をクライアント ID として使用します。

この問題を解結するには、他のデバイスが接続用に使用するクライアント ID を変更するか、またはコアのデフォルトの値を上書きできます。

コアデバイスのデフォルトのクライアント ID を上書きするには

  1. 次のコマンドを実行して AWS IoT 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 マウントに関連していません。

 

解決策: AWS IoT Greengrass Core ソフトウェア v1.9.2 以前を実行している場合、Raspberry Pi の runtime.log でこのエラーが表示されることがあります (ソフトウェアバージョンがエラーメッセージに表示されます)。 この問題を解決するには、AWS IoT Greengrass Core ソフトウェア v1.9.3 or later に更新します。無線による更新の使用については、「AWS IoT Greengrass Core ソフトウェアの OTA 更新」を参照してください。

 

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

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

 

デプロイに関する問題

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

トピック

 

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

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

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

  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 エラーがログに表示される。

解決策: クラウドの 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.

解決策: デプロイに失敗した場合に、このエラーが表示されることがあります。AWS CLI で get-service-role-for-account コマンドを使用して、適切なサービスロールが現在の AWS リージョンの AWS アカウントに関連付けられていることを確認します。Greengrass サービスロールをターゲット AWS リージョンの AWS アカウントに関連付けるには、associate-service-role-to-account を使用します。詳細については、「Greengrass サービスロール」を参照してください。

 

デプロイが完了しない。

解決策: 以下の操作を実行します。

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

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

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

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

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

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

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

 

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

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

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

 

次のエラーが発生する。Deployment <deployment-id> of type NewDeployment for group <group-id> failed error: Error while processing. group config is invalid: 112 or [119 0] don't have rw permission on the file: <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 <deployment-id> of type NewDeployment for group <group-id> failed error: Greengrass deployment error: unable to execute download step in deployment. error while processing: unable to load the group file downloaded: could not find UID based on user name, userName: ggc_user: user: unknown user ggc_user.

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

 

次のエラーが発生する。Deployment <deployment-id> of type NewDeployment for group <group-id> failed error: process start failed: container_linux.go:259: starting container process caused "process_linux.go:250: running exec setns process for init caused \"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 状態のままです。

この問題をテストするには、次のコマンドと出力を使用できます。エンドポイントの リージョン プレースホルダーを 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 を無効にすることです。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 関数の作成に関する問題のトラブルシューティングに役立ちます。

 

次のエラーが発生する。Your 'IsolationMode' configuration for the group is invalid.

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

 

次のエラーが発生する。Your 'IsolationMode' configuration for function with arn <function-arn> is invalid.

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

 

次のエラーが発生する。MemorySize configuration for function with arn <function-arn> is not allowed in IsolationMode=NoContainer.

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

 

次のエラーが発生する。Access Sysfs configuration for function with arn <function-arn> is not allowed in IsolationMode=NoContainer.

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

 

次のエラーが発生する。MemorySize configuration for function with arn <function-arn> is required in IsolationMode=GreengrassContainer.

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

 

次のエラーが発生する。Function <function-arn> refers to resource of type <resource-type> that is not allowed in IsolationMode=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 個を超えるグループに含めることはできません。

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

 

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

以下の情報は、Docker コンテナでの AWS IoT Greengrass コア の実行に関する問題のトラブルシューティングに役立ちます。

 

次のエラーが発生する。Unknown options: -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 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 メッセージが表示されることがあります。Docker サポートで問題「Error: A firewall is blocking file sharing between Windows and the containers」を参照してください。このエラーは、仮想プライベートネットワーク (VPN) にサインインしているときにも発生する場合があり、ネットワーク設定が原因で共有ドライブをマウントできないことがあります。このような場合は、VPN をオフにし、Docker コンテナを再実行します。

 

次のエラーが発生する。Cannot create container for the service 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 がクラッシュするため手動で再起動する必要があります。

解決策: このエラーが 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 の実行」を参照してください。

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

ログがローカルファイルシステムに保存されるように設定している場合は、次の場所を探します。ファイルシステムのログを確認するには、ルート権限が必要です。

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 で送信されるすべてのメッセージは QoS 0 で送信されます。デフォルトでは、AWS IoT Greengrass はメッセージをメモリ内のキューに保存します。したがって、グループのデプロイ後やデバイスの再起動後などに AWS IoT Greengrass コア を再起動すると、未処理のメッセージは失われます。ただし、AWS IoT Greengrass (v1.6 or later) を設定してファイルシステムにメッセージをキャッシュして、コアの再起動でも保持されるようにできます。また、キューサイズを設定することもできます。詳細については、「MQTT メッセージキュー」を参照してください。

注記

デフォルトのインメモリキューを使用する場合、サービスの中断が低いときにグループのデプロイあるいはデバイスの再起動を行うことが推奨されます。

キューサイズを設定する場合、262144 バイト (256 KB) 以上の値になるように注意してください。そうしない場合、AWS IoT Greengrass が正しく起動しなくなることがあります。

シャドウ同期タイムアウト問題のトラブルシューティング

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 IoT Greengrass フォーラムを確認します。

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