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 Core ソフトウェア」を参照してください。
-
Core デバイスに使用可能なローカルストレージがあることを確認します。詳細については、「ストレージ問題のトラブルシューティング」を参照してください。
-
runtime.log
とcrash.log
でエラーメッセージを確認します。詳細については、「ログによるトラブルシューティング」を参照してください。
以下の症状とエラーを検索して、AWS IoT Greengrass コアの問題のトラブルシューティングに役立つ情報を見つけます。
問題
エラー: Error occurred while generating TLS config: ErrUnknownURIScheme
エラー: Runtime failed to start: unable to start workers: container test timed out.
コンテナ化なしの実行から Greengrass コンテナでの実行に変更した後、AWS IoT Greengrass Core ソフトウェアが起動しない。
エラー: unable to accept TCP connection. accept tcp [::]:8000: accept4: too many open files.
AWS IoT Greengrass コアは、ネットワークプロキシを使用するように設定されていて、Lambda 関数は送信接続を行うことができません。
エラー: [Errno 24] 開いている <lambda-function> が多すぎます、[Errno 24] 開いているファイルが多すぎます
エラー: 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 以降にアップグレードします。常に最新バージョンの 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
(/
に存在) を開き、JSON 形式を検証します。例えば、カンマが正しく使用されていることを確認してください。greengrass-root
/config
エラー: Error occurred while generating TLS config: ErrUnknownURIScheme
解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。Greengrass 設定ファイルの crypto セクションのプロパティが有効であることを確認します。エラーメッセージに詳細が説明されています。
config.json
(/
に存在) を開き、greengrass-root
/configcrypto
セクションを確認します。例えば、証明書とキーのパスは正しい 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
/configruntime
オブジェクトに 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 ソフトウェアが起動しない場合に、このエラーが表示されることがあります。このエラーは、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
ファイル (/
に存在) を開き、このファイルの内容を空の JSON オブジェクト (greengrass-root
/ggc/deployment/group{}
) に置き換え、以下のコマンドを実行して 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
にこのエラーが記録されることがあります。このエラーは、umask
が 0022
よりも高い場合に発生します。この問題を解決するには、umask
を 0022
以下に設定する必要があります。値 0022
は、デフォルトで新しいファイルの読み取りアクセス権限をすべてのユーザーに付与します。
エラー: Greengrass daemon running with PID: <process-id>. Some system components failed to start. Check 'runtime.log' for errors.
解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、このエラーが表示されることがあります。固有のエラー情報については、runtime.log
と crash.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 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_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 を上書きするには
-
次のコマンドを実行して Greengrass デーモンを停止します。
cd /
greengrass-root
/ggc/core/ sudo ./greengrassd stop -
su ユーザーとして
を編集用に開きます。greengrass-root
/config/config.json -
coreThing
オブジェクトにcoreClientId
プロパティを追加し、その値をカスタムのクライアント ID に設定します。値は 1 ~ 128 文字で指定します。この値は AWS アカウントの現在の AWS リージョンで一意であることが必要です。"coreClientId": "MyCustomClientId"
-
デーモンを開始します。
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 permitted
や EPERM
などの類似するエラーが表示される場合があります。これらのエラーは、依存関係チェッカーのスクリプトパスによってプラットフォーム上でテストが実行された場合にも発生する可能性があります。
以下のいずれかの解決策を試してください。
-
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
を [ソースパス] および [送信先パス] として指定します。 -
リソースを所有する 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
を [ソースパス] および [送信先パス] として指定します。 -
リソースを所有する Linux グループの OS グループアクセス許可を自動的に追加します。
-
Lambda 関数と関連付けて、読み取り専用アクセスを許可します。
エラー: [ERROR]-runtime execution error: unable to start lambda container. {"errorString": "failed to initialize container mounts: failed to create overlay fs for container: mounting overlay at /greengrass/ggc/packages/<ggc-version>/rootfs/merged failed: failed to mount with args source=\"no_source\" dest=\"/greengrass/ggc/packages/<ggc-version>/rootfs/merged\" fstype=\"overlay\" flags=\"0\" data=\"lowerdir=/greengrass/ggc/packages/<ggc-version>/dns:/,upperdir=/greengrass/ggc/packages/<ggc-version>/rootfs/upper,workdir=/greengrass/ggc/packages/<ggc-version>/rootfs/work\": too many levels of symbolic links"}
解決策: AWS IoT Greengrass Core ソフトウェアが起動しない場合に、runtime.log
ファイルにこのエラーが表示されることがあります。これは Debian オペレーティングシステムで生じやすい問題です。
この問題を解決するには、次の操作を行います。
-
AWS IoT Greengrass Core ソフトウェアを v1.9.3 以降にアップグレードします。これにより、この問題は自動的に解決されます。
-
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. Caused by: 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 デバイスにデプロイされます。
デプロイを再デプロイするには (コンソール)
-
グループの設定ページで、[デプロイ] を選択します。このページには、日付と時刻、グループバージョン、各デプロイ試行のステータスなど、グループのデプロイ履歴が表示されます。
-
再デプロイするデプロイが含まれている行を見つけます。再デプロイするデプロイを選択し、[Redeploy] (再デプロイ) を選択します。
デプロイを再デプロイするには (CLI)
-
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 とデプロイ ID にサンプルの値を使用しています。コマンドを実行するときは、サンプルの値を置き換えてください。
-
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" }
-
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 デーモンが実行されていることを確認します。コアデバイスのターミナルで以下のコマンドを実行し、デーモンが実行されているかどうかを確認します。必要ならばデーモンを起動します。
デーモンが実行中かどうかを確認するには、以下を実行します。
ps aux | grep -E 'greengrass.*daemon'
出力に
root
で実行中の/greengrass/ggc/packages/1.11.6/bin/daemon
のエントリが含まれていれば、デーモンは実行されています。パス内のバージョンは、コアデバイスにインストールされている AWS IoT Greengrass Core ソフトウェアのバージョンによって異なります。
デーモンを開始するには、以下を実行します。
cd /greengrass/ggc/core/ sudo ./greengrassd start
-
コアデバイスが接続されていて、コアの接続エンドポイントが適切に設定されていることを確認してください。
エラー: Unable to find java or java8 executables, or the error: Deployment <deployment-id> of type NewDeployment for group <group-id> failed error: worker with <worker-id> failed to initialize with reason Installed Java version must be greater than or equal to 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 証明書ファイルは /
にあります。コアデバイス上の場所を見つけるには、config.json の greengrass-root
/certs/root.ca.pemcrypto.caPath
のプロパティを確認します。
注記
greengrass-root
は、デバイスで AWS IoT Greengrass Core ソフトウェアがインストールされているパスを表します。通常、これは /greengrass
ディレクトリです。
エラー: 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.json
で allowFunctionsToRunAsRoot
の値を 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
グループがデバイスに存在する必要があります。ユーザーとグループを追加する方法については、このステップを参照してください。表示されているとおりに正確に名前を入力してください。
エラー: [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
を [ソースパス] および [送信先パス] として指定します。 -
リソースを所有する Linux グループの OS グループアクセス許可を自動的に追加します。
-
Lambda 関数と関連付けて、読み取り専用アクセスを許可します。
エラー: 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
状態のままです。
この問題をテストするには、次のコマンドと出力を使用できます。エンドポイントの region
プレースホルダーを AWS リージョンに置き換えます。
$
ping greengrass-ats.iot.region
.amazonaws.comping: greengrass-ats.iot.
region
.amazonaws.com: Name or service not known
$
systemd-resolve greengrass-ats.iot.region
.amazonaws.comgreengrass-ats.iot.
region
.amazonaws.com: resolve call failed: DNSSEC validation failed: failed-auxiliary
考えられる解決策の 1 つは、DNSSEC
を無効にすることです。DNSSEC
が false
の場合、DNS ルックアップは DNSSEC
で検証されません。詳細については、systemd
の既知の問題
-
/etc/systemd/resolved.conf
にDNSSEC=false
を追加します。 -
systemd-resolved
を再起動します。
resolved.conf
および DNSSEC
の詳細については、ターミナルで man resolved.conf
を実行してください。
グループの作成と関数の作成に関する問題
以下の情報は、AWS IoT Greengrass グループまたは Greengrass Lambda 関数の作成に関する問題のトラブルシューティングに役立ちます。
問題
エラー: Your 'IsolationMode' configuration for the group is invalid.
解決策: このエラーは、function-definition-version
の DefaultConfig
で IsolationMode
値がサポートされていない場合に発生します。サポートされている値は、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.
解決策: このエラーは、AccessSysfs
を true
に指定しているときに、コンテナ化なしで実行しようとした場合に発生します。コンテナ化を使用せずに実行する 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.Device
、Local.Volume
、ML_Model.SageMaker.Job
、ML_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 関数は、機械学習リソースをアタッチするときにアクセス権限を設定できません。<function-arn> は、リソースアクセスポリシーでアクセス権限 <ro/rw> を持つ機械学習リソース <resource-id> を参照します。
解決策: コンテナ化されていない Lambda 関数が機械学習リソースに対する関数レベルのアクセス権限を指定した場合、このエラーが表示されます。コンテナ化されていない関数は、機械学習リソースに定義されているリソース所有者のアクセス権限からアクセス権限を継承する必要があります。この問題を解決するには、コンソールから [inherit resource owner permissions] (リソース所有者のアクセス許可を継承する) を選択するか、API を使用して Lambda 関数のリソースアクセスポリシーからアクセス権限を削除するかを選択します。
関数 <function-arn> は機械学習リソース <resource-id> を参照しますが、ResourceAccessPolicy とリソースの OwnerSetting のどちらにもアクセス権限がありません。
解決策: このエラーは、機械学習リソースへのアクセス権限が、アタッチされた Lambda 関数またはリソースに対して設定されていない場合に表示されます。この問題を解決するには、Lambda 関数の ResourceAccessPolicy プロパティか、またはリソースの OwnerSetting プロパティにアクセス権限を設定します。
関数 <function-arn> は \"rw\" アクセス権限で機械学習リソース <resource-id> を参照しますが、リソース所有者設定の 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 コアの実行に関する問題のトラブルシューティングに役立ちます。
エラー: 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. Networking will not work.
解決策: 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 コンテナを再実行します。
エラー: An error occurred (AccessDeniedException) when calling the GetAuthorizationToken operation: 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. 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 グループのログ設定を構成できます。ログを 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/system/localwatch/-
Greengrass ログを CloudWatch Logs にアップロードする処理を行う AWS IoT Greengrass コンポーネントのログが含まれています。CloudWatch で 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 はメッセージをメモリ内のキューに保存します。したがって、グループのデプロイ後やデバイスの再起動後などに 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
/configsystem.shadowSyncTimeout
フィールドを追加します。例:
{ "system": { "shadowSyncTimeout": 10 }, "coreThing": { "caPath": "root-ca.pem", "certPath": "cloud.pem.crt", "keyPath": "cloud.pem.key", ... }, ... }
config.json
に shadowSyncTimeout
値が指定されていない場合は、デフォルト値の 5 秒が使用されます。
注記
AWS IoT Greengrass Core ソフトウェア v1.6 以前では、デフォルトの shadowSyncTimeout
は 1 秒です。
AWS re:Post の確認
このトピックのトラブルシューティング情報を使用しても問題を解決できない場合は、AWS IoT Greengrass のトラブルシューティング を検索するか、AWS re:Post の AWS IoT Greengrass タグ