翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# IDT for AWS IoT Greengrass V2 のトラブルシューティング
IDT for AWS IoT Greengrass V2 は、エラーのタイプに基づいてさまざまな場所にエラーを書き込みます。IDT はコンソール、ログファイル、テストレポートにエラーを書き込みます。
## エラーをどこで探せばよいか
テスト実行中はエラーの概要がコンソールに表示され、テストがすべて完了すると、失敗したテストの概要が表示されます。`awsiotdevicetester_report.xml` には、テストが失敗する原因となったすべてのエラーの概要が含まれます。IDT はテスト実行ごとのログファイルを、テスト実行用の UUID を持つディレクトリに保存します。これはテスト実行中はコンソールに表示されます。
IDT テストログのディレクトリは `/results//logs/` です。このディレクトリには、テーブルに表示されている次のファイルが含まれています。これは、デバッグ時に便利です。
| システム | 説明 |
| --- | --- |
| test\$1manager.log | テストの実行中にコンソールに書き込まれたログ。このファイルの最後にある結果の概要には、失敗したテストのリストが含まれます。 失敗に関する情報は、このファイルの警告ログとエラーログで確認できます。 |
| test-group-id/test-case-id/test-name.log | テストグループ内の特定のテストの詳細なログ。Greengrass コンポーネントをデプロイするテストの場合、テストケースログファイルは greengrass-test-run.log と呼ばれます。 |
| test-group-id/test-case-id/greengrass.log | AWS IoT Greengrass Core ソフトウェアの詳細ログ。IDT は、デバイスに AWS IoT Greengrass Core ソフトウェアをインストールするテストを実行するときに、テスト対象のデバイスからこのファイルをコピーします。このログファイルのメッセージの詳細については、「[トラブルシューティング AWS IoT Greengrass V2](troubleshooting.md)」を参照してください。 |
| test-group-id/test-case-id/component-name.log | テスト実行中にデプロイされる Greengrass コンポーネントの詳細なログ。IDT は、特定のコンポーネントをデプロイするテストを実行するときに、テスト対象のデバイスからコンポーネントログファイルをコピーします。各コンポーネントログファイルの名前は、デプロイされたコンポーネントの名前に対応します。このログファイルのメッセージの詳細については、「[トラブルシューティング AWS IoT Greengrass V2](troubleshooting.md)」を参照してください。 |
## IDT for AWS IoT Greengrass V2 エラーの解決
IDT for を実行する前に AWS IoT Greengrass、正しい設定ファイルを用意してください。解析エラーや設定エラーが表示される場合は、まず環境に適した設定テンプレートを見つけて使用します。
それでも問題が解決されない場合は、次のデバッグプロセスを参照してください。
**Topics**
+ [エイリアスの解決エラー](#alias-resolution-errors)
+ [競合エラー](#conflict-error)
+ [テストを開始できなかったエラー](#could-not-start-test)
+ [Docker 認定イメージが存在するエラー](#docker-qualification-image-exists)
+ [認証情報を読み込めませんでした](#failed-to-read-credential-windows)
+ [事前インストールされた Greengrass で発生する Guice エラー](#guice-errors)
+ [無効な署名の例外](#invalid-signature-exception-lambda)
+ [機械学習認定エラー](#machine-learning-qualification-failure)
+ [オープンテストフレームワーク (OTF) のデプロイ失敗](#otf-deployment-failure)
+ [解析エラー](#parse-error)
+ [アクセス拒否エラー](#permission-denied-pwd-sudo)
+ [認定レポート生成エラー](#qualification-report-policy-error)
+ [必須パラメータが見つからないエラー](#required-param-missing)
+ [macOS でのセキュリティ例外](#security-exception-macos)
+ [SSH 接続エラー](#ssh-connect-errors)
+ [ストリームマネージャー認定エラー](#stream-manager-qualification-failure)
+ [タイムアウトエラー](#test-timeout)
+ [バージョンチェックエラー](#version-compatibility-check-failure)
### エイリアスの解決エラー
カスタムテストスイートを実行すると、コンソールおよび `test_manager.log` で以下のエラーが表示される場合があります。
```
Couldn't resolve placeholders: couldn't do a json lookup: index out of range
```
このエラーは、IDT テストオーケストレーターで設定されたエイリアスが正しく解決されない場合、または解決された値が設定ファイル内に存在しない場合に発生します。このエラーを解決するには、`device.json` および `userdata.json ` にテストスイートに必要な正しい情報を記載するようにしてください。 AWS IoT Greengrass 認定に必要な設定については、「」を参照してください[認定スイートを実行するように IDT AWS IoT Greengrass 設定を構成する](set-config.md)。
### 競合エラー
複数のデバイスで AWS IoT Greengrass 認定スイートを同時に実行すると、次のエラーが表示されることがあります。
```
ConflictException: Component [com.example.IDTHelloWorld : 1.0.0] for account [account-id] already exists with state: [DEPLOYABLE] { RespMetadata: { StatusCode: 409, RequestID: “id” }, Message_: “Component [com.example.IDTHelloWorld : 1.0.0] for account [account-id] already exists with state: [DEPLOYABLE]” }
```
AWS IoT Greengrass 認定スイートでは、同時テスト実行はまだサポートされていません。認定スイートは、デバイスごとに順番に実行してください。
### テストを開始できなかったエラー
テストを開始しようとしたときに発生した障害を示すエラーが表示される場合があります。考えられる原因にはさまざまなものがあるため、以下を実行します。
+ 実行コマンド内のプール名が実際に存在することを確認します。IDT は、プール名を `device.json` ファイルから直接参照します。
+ プール内のデバイスの設定パラメータが正しいことを確認します。
### Docker 認定イメージが存在するエラー
Docker アプリケーションマネージャーの認定テストでは、テスト対象のデバイスの認定に、Amazon ECR の `amazon/amazon-ec2-metadata-mock` コンテナイメージが使用されます。
テスト対象のデバイスの Docker コンテナにイメージがすでに存在する場合は、以下のエラーが表示される場合があります。
```
The Docker image amazon/amazon-ec2-metadata-mock:version already exists on the device.
```
以前このイメージをダウンロードして、デバイスで `amazon/amazon-ec2-metadata-mock` コンテナを実行していた場合は、認定テストを実行する前に、テスト対象のデバイスからこのイメージを削除してください。
### 認証情報を読み込めませんでした
Windows デバイスをテストするときに、テスト対象のデバイスへの接続に使用するユーザーがそのデバイスの認証情報マネージャーで設定されていないと、`greengrass.log` ファイルに `Failed to read credential` エラーが表示される場合があります。
このエラーを解決するには、テスト対象のデバイスの認証情報マネージャーで IDT ユーザーのユーザーとパスワードを設定します。
詳細については、「[Windows デバイスのユーザー認証情報を設定する](device-config-setup.md#configure-windows-user-for-idt)」を参照してください。
### 事前インストールされた Greengrass で発生する Guice エラー
事前インストールされた Greengrass を使用して IDT を実行している際、`Guice` または `ErrorInCustomProvider` というエラーが発生した場合は、ファイル `userdata.json` 内の `InstalledDirRootOnDevice` が、Greengrass のインストールフォルダに設定されているかどうかを確認します。IDT は `/config/effectiveConfig.yaml` の下の `effectiveConfig.yaml` ファイルをチェックします。
詳細については、「[Windows デバイスのユーザー認証情報を設定する](device-config-setup.md#configure-windows-user-for-idt)」を参照してください。
### 無効な署名の例外
Lambda 認定テストを実行するとき、IDT ホストマシンにネットワークアクセスの問題が発生すると、`invalidsignatureexception` エラーが発生します。ルーターをリセットして、テストを再度実行してください。
### 機械学習認定エラー
機械学習 (ML) 認定テストを実行すると、デバイスが AWS提供された ML コンポーネントのデプロイ[要件を満た](dlr-component.md#dlr-component-requirements)していない場合、認定に失敗することがあります。ML 認定エラーのトラブルシューティングを行うには、以下の手順を実行します。
+ テスト実行中にデプロイされたコンポーネントのコンポーネントログで、エラーの詳細を確認します。コンポーネントログは `/results//logs/` ディレクトリにあります。
+ `-Dgg.persist=installed.software` の引数を失敗したテストケースの `test.json` ファイルに追加します。`test.json` ファイルは `/tests/GGV2Q_version directory. ` にあります。
### オープンテストフレームワーク (OTF) のデプロイ失敗
OTF テストでデプロイが失敗しなかった場合は、`TempResourcesDirOnDevice` および `InstallationDirRootOnDevice` の親フォルダーに対するアクセス許可に原因があると考えられます。このフォルダーへのアクセス許可を適切に作成するには、次のコマンドを実行します。`folder-name` は、実際の親フォルダーの名前に置き換えます。
```
sudo chmod 755 folder-name
```
### 解析エラー
JSON 設定のタイプミスは、解析エラーにつながることがあります。ほとんどの場合、JSON ファイルで括弧やカンマ、引用符を忘れたことが原因です。IDT は、JSON 検証を行い、デバッグ情報を出力します。エラーが発生した行、構文エラーの行番号と列番号が出力されます。この情報だけでエラーの修正が可能なはずですが、それでもエラーを特定できない場合は、IDE、テキストエディタ (Atom、Sublime など)、またはオンラインツール (JSONLint など) を使って手動で検証できます。
### アクセス拒否エラー
IDT は、テスト対象デバイスのさまざまなディレクトリやファイルに対してオペレーションを実行します。一部のオペレーションにはルートアクセスが必要です。これらのオペレーションを自動化するには、パスワードを入力することなく、IDT で sudo を使用してコマンドを実行する必要があります。
パスワードを入力することなく、sudo にアクセスを許可するには、以下の手順を実行します。
**注記**
`user` および `username` は、テスト対象デバイスにアクセスするために IDT で使用する SSH ユーザーを指します。
1. SSH ユーザーを sudo グループに追加するには **sudo usermod -aG sudo **** を使用します。
1. サインアウトし、再度サインインして、変更を反映します。
1. `/etc/sudoers` ファイルを開き、ファイルの末尾に次の行を追加します: ` ALL=(ALL) NOPASSWD: ALL`
**注記**
ベストプラクティスとして、`/etc/sudoers` を編集するときは **sudo visudo** を使用することをお勧めします。
### 認定レポート生成エラー
IDT は、 AWS IoT Greengrass V2 認定スイート (GGV2Q) の 4 つの`major.minor`最新バージョンをサポートし、 AWS Partner デバイスカタログにデバイスを含める AWS Partner Network ために に送信できる認定レポートを生成します。以前のバージョンの認定スイートでは、認定レポートは生成されません。
サポートポリシーについてご質問がある場合は、 [AWS サポート](https://aws.amazon.com/contact-us/) までお問い合わせください。
### 必須パラメータが見つからないエラー
IDT が新しい機能を追加すると、設定ファイルに変更が加えられる可能性があります。古い設定ファイルを使用すると、設定が破損する可能性があります。このような場合は、`/results//logs` にある `.log` ファイルに、すべての不足しているパラメータが明確に示されています。また、IDT では、JSON 設定ファイルのスキーマを検証し、サポートされている最新のバージョンが使用されているか検証します。
### macOS でのセキュリティ例外
macOS ホストコンピュータで IDT を実行すると、IDT の実行がブロックされます。IDT を実行するには、セキュリティ例外を IDT ランタイム機能の一部である実行可能ファイルに付与します。ホストコンピュータに警告メッセージが表示されたら、該当する実行ファイルごとに次の操作を行います。
**セキュリティ例外を IDT 実行可能ファイルに付与するには**
1. macOS コンピュータの Apple メニューで、**[System Preferences]** (システム環境設定) を開きます。
1. **[Security & Privacy]** (セキュリティとプライバシー) を選択し、**[General]** (一般) タブでロックアイコンを選択して、セキュリティ設定を変更します。
1. ブロックされた `devicetester_mac_x86-64` の場合は、メッセージ `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` を探して **[Allow Anyway]** (すべてのアプリケーションを許可) を選択します。
1. 関連するすべての実行可能ファイルを完了するまで、IDT テストを再開します。
### SSH 接続エラー
IDT からテスト対象デバイスに接続できない場合は、接続エラーのログが `/results//logs/.log` に記録されます。SSH メッセージは、このログファイルの上部に表示されます。テスト対象デバイスへの接続は IDT が実行する最初のオペレーションの 1 つであるためです。
ほとんどの Windows 設定では、PuTTy ターミナルアプリケーションを使用して Linux ホストに接続します。このアプリケーションは、標準 PEM プライベートキーファイルを PPK と呼ばれる独自の Windows 形式に変換することを要求します。`device.json` ファイルで SSH を設定する場合は、PEM ファイルを使用してください。PPK ファイルを使用する場合、IDT は AWS IoT Greengrass デバイスとの SSH 接続を作成できず、テストを実行できません。
IDT v4.4.0 以降、テスト対象のデバイスで SFTP を有効にしていない場合、ログファイルに次のエラーが表示される場合があります。
```
SSH connection failed with EOF
```
このエラーを解決するには、デバイスで SFTP を有効にします。
### ストリームマネージャー認定エラー
ストリームマネージャー認定テストを実行すると、`com.aws.StreamManagerExport.log` ファイルに以下のエラーが表示されることがあります。
```
Failed to upload data to S3
```
このエラーは、IDT がテスト対象のデバイスにエクスポートする環境 AWS 認証情報を使用する代わりに、ストリームマネージャーがデバイスの `~/root/.aws/credentials` ファイル内の認証情報を使用する場合に発生する可能性があります。この問題を回避するには、デバイスの `credentials` ファイルを削除し、認定テストを再実行してください。
### タイムアウトエラー
各テストのタイムアウトを長くするには、各テストのタイムアウトのデフォルト値に適用されるタイムアウト乗数を指定します。このフラグに設定された値はすべて、1.0 以上である必要があります。
タイムアウトの乗数を使用するには、テストの実行時に `--timeout-multiplier` フラグを使用します。例:
```
./devicetester_linux run-suite --suite-id GGV2Q_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5
```
詳細については、`run-suite --help` を実行してください。
一部のタイムアウトエラーは、設定の問題により IDT テストケースを完了できない場合に発生します。このようなエラーは、タイムアウト乗数を増やしても解決することはできません。テスト実行のログを使用して、基本的な設定の問題に対するトラブルシューティングを行ってください。
+ MQTT または Lambda コンポーネントのログに`Access denied` エラーが含まれる場合、Greengrass インストールフォルダに適切なファイルのアクセス許可が与えられていない可能性があります。`userdata.json` ファイルで定義したインストールパス内のフォルダごとに、以下のコマンドを実行します。
```
sudo chmod 755 folder-name
```
+ Greengrass ログに Greengrass CLI のデプロイが完了していないことが示されている場合は、以下の手順を実行します。
+ テスト対象デバイスに `bash` がインストールされていることを確認します。
+ `userdata.json` ファイルに `GreengrassCliVersion` 設定パラメータが含まれている場合、それを削除します。IDT v4.1.0 以降のバージョンでは、このパラメータは廃止されています。詳細については、「[userdata.json を設定する](set-config.md#userdata-config)」を参照してください。
+ Lambda デプロイテストが「Validating Lambda publish: time out」(Lambda の発行を検証しています: タイムアウト) というエラーメッセージで失敗し、テストログファイル(`idt-gg2-lambda-function-idt-.log`) に `Error: Could not find or load main class com.amazonaws.greengrass.runtime.LambdaRuntime.` というエラーが表示された場合は、次を実行します。
+ `userdata.json` ファイルで `InstallationDirRootOnDevice` のために使用されたフォルダを検証します。
+ デバイスに正しいユーザー許可が設定されていることを確認してください。詳細については、「[デバイスに対するユーザーのアクセス許可を設定する](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-config-setup.html#root-access)」を参照してください。
### バージョンチェックエラー
IDT ユーザーの AWS ユーザー認証情報に必要な IAM アクセス許可がない場合、IDT は次のエラーを発行します。
```
Failed to check version compatibility
```
必要な IAM アクセス許可を持たない AWS ユーザー。