

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Solução de problemas de IDT para V2 AWS IoT Greengrass
<a name="idt-troubleshooting"></a>

O IDT for AWS IoT Greengrass V2 grava erros em vários locais com base no tipo de erro. O IDT grava erros no console, nos arquivos de registro e nos relatórios de teste. 

## Onde procurar por erros
<a name="where-to-look"></a>

Os erros gerais serão exibidos no console durante a execução, e um resumo dos testes com falha com o erro será exibido quando todos os testes forem concluídos. O arquivo `awsiotdevicetester_report.xml` contém um resumo de todos os erros que causaram a falha do teste. O IDT armazena os arquivos de log de cada execução de teste em um diretório com um UUID para a execução do teste, exibido no console durante a execução do teste.

O diretório de logs de teste do IDT é`<device-tester-extract-location>/results/<execution-id>/logs/`. Esse diretório contém os seguintes arquivos exibidos na tabela. Isso é útil para depuração.


| Arquivo | Description | 
| --- | --- | 
| test\$1manager.log |  Os logs gravados no console durante a execução do teste. O resumo dos resultados no final desse arquivo inclui uma lista dos testes que falharam. Os logs de aviso e de erro nesse arquivo podem fornecer algumas informações sobre as falhas.   | 
| test-group-id/test-case-id/test-name.log | Logs detalhados para o teste específico em um grupo de testes. Para testes que implantam componentes do Greengrass, o arquivo de log do caso de teste é chamado. greengrass-test-run.log | 
| test-group-id/test-case-id/greengrass.log | Registros detalhados AWS IoT Greengrass do software Core. O IDT copia esse arquivo do dispositivo em teste quando executa testes que instalam o software AWS IoT Greengrass Core no dispositivo. Para obter mais informações sobre as mensagens desse arquivo de log, consulte [Solução de problemas AWS IoT Greengrass V2](troubleshooting.md). | 
| test-group-id/test-case-id/component-name.log | Logs detalhados dos componentes do Greengrass que são implantados durante as execuções de teste. O IDT copia os arquivos de log de componentes do dispositivo em teste quando executa testes que implantam componentes específicos. O nome do arquivo de log de cada componente corresponde ao nome do componente implantado. Para obter mais informações sobre as mensagens desse arquivo de log, consulte [Solução de problemas AWS IoT Greengrass V2](troubleshooting.md). | 

## Resolvendo erros de IDT para V2 AWS IoT Greengrass
<a name="idt-gg-resolve-errors"></a>

Antes de executar o IDT for AWS IoT Greengrass, instale os arquivos de configuração corretos. Se você recebe erros de análise e configuração, o primeiro passo é localizar e usar um modelo de configuração apropriado para seu ambiente.

Se você ainda estiver com problemas, consulte o processo de depuração a seguir.

**Topics**
+ [Erros de resolução de aliases](#alias-resolution-errors)
+ [Erros de conflito](#conflict-error)
+ [Erro: Não foi possível iniciar teste](#could-not-start-test)
+ [Existem erros na imagem de qualificação do Docker](#docker-qualification-image-exists)
+ [Falha ao ler a credencial](#failed-to-read-credential-windows)
+ [Erros do Guide com PreInstalled o Greengrass](#guice-errors)
+ [Resposta da exceção inválida](#invalid-signature-exception-lambda)
+ [Erros de qualificação do Machine Learning](#machine-learning-qualification-failure)
+ [Implantações com falha no Open Test Framework (OTF)](#otf-deployment-failure)
+ [Erros de análise](#parse-error)
+ [Erros de permissão negada](#permission-denied-pwd-sudo)
+ [Erro de geração de relatórios de qualificação](#qualification-report-policy-error)
+ [Erro de parâmetro necessário ausente](#required-param-missing)
+ [Exceção de segurança no macOS](#security-exception-macos)
+ [Erros de conexão SSH](#ssh-connect-errors)
+ [Erros de qualificação do gerenciador de fluxos](#stream-manager-qualification-failure)
+ [Erros de tempo limite](#test-timeout)
+ [Erros de verificação de versão](#version-compatibility-check-failure)

### Erros de resolução de aliases
<a name="alias-resolution-errors"></a>

Ao executar suítes de testes personalizadas, você pode ver o seguinte erro no console e no `test_manager.log`. 

```
Couldn't resolve placeholders: couldn't do a json lookup: index out of range
```

Esse erro pode ocorrer quando os aliases configurados no orquestrador de testes do IDT não são resolvidos corretamente ou se os valores resolvidos não estão presentes nos arquivos de configuração. Para resolver esse erro, certifique-se de que seu `device.json` e `userdata.json ` contenha as informações corretas necessárias para sua suíte de testes. Para obter informações sobre a configuração necessária para a AWS IoT Greengrass qualificação, consulte[Defina as configurações de IDT para executar o pacote de AWS IoT Greengrass qualificação](set-config.md).

### Erros de conflito
<a name="conflict-error"></a>

Você pode ver o seguinte erro ao executar o pacote de AWS IoT Greengrass qualificação simultaneamente em mais de um dispositivo.

```
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]” }
```

A execução simultânea de testes ainda não é suportada pelo pacote de AWS IoT Greengrass qualificação. Execute o conjunto de qualificação sequencialmente para cada dispositivo.

### Erro: Não foi possível iniciar teste
<a name="could-not-start-test"></a>

Você pode encontrar erros que apontam para falhas que ocorreram quando o teste estava tentando iniciar. Há várias causas possíveis e, portanto, faça o seguinte:
+ Verifique se o nome do grupo incluído no comando de execução realmente existe. O IDT faz referência ao nome do grupo diretamente do seu arquivo `device.json`.
+ Verifique se os dispositivos no grupo têm os parâmetros de configuração corretos.

### Existem erros na imagem de qualificação do Docker
<a name="docker-qualification-image-exists"></a>

Os testes de qualificação do Docker Application Manager usam a imagem do contêiner `amazon/amazon-ec2-metadata-mock` no Amazon ECR para qualificar o dispositivo em teste.

Você pode receber o seguinte erro se a imagem já estiver presente em um contêiner do Docker no dispositivo em teste.

```
The Docker image amazon/amazon-ec2-metadata-mock:version already exists on the device.
```

Se você baixou essa imagem anteriormente e executou o contêiner `amazon/amazon-ec2-metadata-mock` em seu dispositivo, certifique-se de remover essa imagem do dispositivo em teste antes de executar os testes de qualificação.

### Falha ao ler a credencial
<a name="failed-to-read-credential-windows"></a>

Ao testar dispositivos Windows, você pode encontrar o erro `Failed to read credential` no arquivo `greengrass.log` se o usuário que você usa para se conectar ao dispositivo em teste não estiver configurado no gerenciador de credenciais desse dispositivo. 

Para resolver esse erro, configure o usuário e a senha do usuário do IDT no gerenciador de credenciais do dispositivo em teste.

Para obter mais informações, consulte [Configurar credenciais de usuário para dispositivos Windows](device-config-setup.md#configure-windows-user-for-idt).

### Erros do Guide com PreInstalled o Greengrass
<a name="guice-errors"></a>

Ao executar o IDT com o PreInstalled Greengrass, se você encontrar um erro `Guice` de `ErrorInCustomProvider` ou, verifique se o `userdata.json` arquivo está configurado `InstalledDirRootOnDevice` para a pasta de instalação do Greengrass. O IDT verifica o arquivo `effectiveConfig.yaml` em `<InstallationDirRootOnDevice>/config/effectiveConfig.yaml`.

Para obter mais informações, consulte [Configurar credenciais de usuário para dispositivos Windows](device-config-setup.md#configure-windows-user-for-idt).

### Resposta da exceção inválida
<a name="invalid-signature-exception-lambda"></a>

Ao executar testes de qualificação do Lambda, você pode encontrar o erro `invalidsignatureexception` se sua máquina host IDT tiver problemas de acesso à rede. Reinicie o roteador e execute os testes novamente. 

### Erros de qualificação do Machine Learning
<a name="machine-learning-qualification-failure"></a>

Ao executar testes de qualificação de aprendizado de máquina (ML), você pode encontrar falhas de qualificação se seu dispositivo não atender [aos requisitos](dlr-component.md#dlr-component-requirements) para implantar os componentes AWS de ML fornecidos. Para solucionar erros de qualificação do ML, faça o seguinte: 
+ Procure detalhes de erro nos logs dos componentes que foram implantados durante a execução do teste. Os logs de componentes estão localizados no diretório `<device-tester-extract-location>/results/<execution-id>/logs/<test-group-id>`.
+ Adicione o argumento `-Dgg.persist=installed.software` ao arquivo `test.json` para o caso de teste com falha. O arquivo `test.json` está localizado no `<device-tester-extract-location>/tests/GGV2Q_version directory. `

### Implantações com falha no Open Test Framework (OTF)
<a name="otf-deployment-failure"></a>

Se os testes OTF falharem em concluir a implantação, uma causa provável pode ser as permissões definidas para a pasta principal de `TempResourcesDirOnDevice` e `InstallationDirRootOnDevice`. Para definir corretamente as permissões dessa pasta, execute o comando a seguir. Substitua `folder-name` pelo nome da pasta pai.

```
sudo chmod 755 folder-name
```

### Erros de análise
<a name="parse-error"></a>

Erros ortográficos em uma configuração JSON podem resultar em erros de análise. Na maioria dos casos, o problema é resultado da omissão de um colchete, vírgula ou aspas de seu arquivo JSON. O IDT executa a validação do JSON e imprime as informações de depuração. Ele imprime a linha em que ocorreu o erro, o número da linha e o número da coluna do erro de sintaxe. Essas informações devem ser suficientes para ajudá-lo a corrigir o erro, mas se você ainda não conseguir localizar o erro, poderá realizar a validação manualmente em seu IDE, em um editor de texto, como Atom ou Sublime, ou por meio de uma ferramenta on-line, como JSONLint.

### Erros de permissão negada
<a name="permission-denied-pwd-sudo"></a>

O ITD executa operações em vários diretórios e arquivos em um dispositivo em teste. Algumas dessas operações exigem acesso raiz. Para automatizar essas operações, o IDT deverá ser capaz de executar comandos com sudo sem digitar uma senha. 

Siga estas etapas para permitir o acesso do sudo sem digitar uma senha.

**nota**  
`user` e `username` se referem ao usuário SSH usado pelo IDT para acessar o dispositivo em teste.

1. Use **sudo usermod -aG sudo *<ssh-username>*** para adicionar o usuário SSH ao grupo sudo.

1. Saia e faça login para que as alterações entrem em vigor.

1. Abra o arquivo `/etc/sudoers` e adicione a linha a seguir ao final do arquivo: `<ssh-username> ALL=(ALL) NOPASSWD: ALL`
**nota**  
Como prática recomendada, recomendamos que você use **sudo visudo** ao editar `/etc/sudoers`.

### Erro de geração de relatórios de qualificação
<a name="qualification-report-policy-error"></a>

O IDT suporta as quatro `major.minor` versões mais recentes do pacote de qualificação AWS IoT Greengrass V2 (GGV2Q) para gerar relatórios de qualificação que você pode enviar AWS Partner Network para incluir seus dispositivos no Catálogo de AWS Partner dispositivos. As versões anteriores do pacote de qualificação não geram relatórios de qualificação.

Se tiver dúvidas sobre a política de suporte, entre em contato com o [AWS Support](https://aws.amazon.com/contact-us/).

### Erro de parâmetro necessário ausente
<a name="required-param-missing"></a>

Quando o IDT adiciona novos recursos, ele pode introduzir alterações nos arquivos de configuração. O uso de um arquivo de configuração antigo pode danificar sua configuração. Se isso acontecer, o arquivo `<test_case_id>.log`, em `/results/<execution-id>/logs`, listará explicitamente todos os parâmetros ausentes. O IDT também valida os esquemas do arquivo de configuração JSON para verificar se você está usando a versão mais recente compatível.

### Exceção de segurança no macOS
<a name="security-exception-macos"></a>

Quando você executa o IDT em um computador host macOS, ele impede a execução do IDT. Para executar o IDT, conceda uma exceção de segurança aos executáveis que fazem parte da funcionalidade de runtime do IDT. Ao ver a mensagem de aviso exibida no computador host, faça o seguinte para cada um dos executáveis aplicáveis:

**Para conceder uma exceção de segurança a executáveis do IDT**

1. No computador macOS, no menu Apple, abra **Preferências do Sistema**.

1. Selecione **Segurança e privacidade** e, em seguida, na guia **Geral**, escolha o ícone de cadeado para fazer alterações nas configurações de segurança.

1. Caso `devicetester_mac_x86-64` esteja bloqueado, procure pela mensagem `"devicetester_mac_x86-64" was blocked from use because it is not from an identified developer.` e escolha **Permitir mesmo assim**.

1. Continue os testes de IDT até concluir todos os executáveis envolvidos.

### Erros de conexão SSH
<a name="ssh-connect-errors"></a>

Quando o IDT não consegue se conectar a um dispositivo em teste, ele registra as falhas de conexão em `/results/<execution-id>/logs/<test-case-id>.log`. As mensagens de SSH aparecem na parte superior desse arquivo de log, pois a conexão com um dispositivo em teste é uma das primeiras operações executadas pelo IDT.

A maioria das configurações do Windows usa o aplicativo de TTy terminal Pu para se conectar aos hosts Linux. Essa aplicação requer que os arquivos de chave privada PEM padrão sejam convertidos em um formato Windows proprietário chamado PPK. Se você configurar o SSH em seu arquivo `device.json`, use arquivos PEM. Se você usa um arquivo PPK, o IDT não pode criar uma conexão SSH com o AWS IoT Greengrass dispositivo e não pode executar testes.

A partir do IDT v4.4.0, se você não tiver habilitado o SFTP no dispositivo em teste, talvez veja o seguinte erro no arquivo de log.

```
SSH connection failed with EOF
```

Para corrigir esse erro, habilite o SFTP no dispositivo.

### Erros de qualificação do gerenciador de fluxos
<a name="stream-manager-qualification-failure"></a>

Ao executar testes de qualificação do gerenciador de fluxos, você poderá ver o seguinte erro no `com.aws.StreamManagerExport.log` arquivo.

```
Failed to upload data to S3
```

Esse erro pode ocorrer quando o gerenciador de stream usa AWS as credenciais no `~/root/.aws/credentials` arquivo em seu dispositivo em vez de usar as credenciais de ambiente que o IDT exporta para o dispositivo em teste. Para evitar esse problema, exclua o arquivo `credentials` do seu dispositivo e execute novamente o teste de qualificação.

### Erros de tempo limite
<a name="test-timeout"></a>

Você pode aumentar o tempo limite para cada teste especificando um multiplicador de tempo limite, que será aplicado ao valor padrão de cada tempo limite do teste. Qualquer valor configurado para esse sinalizador deve ser maior que ou igual a 1.0.

Para usar o multiplicador de tempo limite, use o sinalizador `--timeout-multiplier` ao executar os testes. Por exemplo:

```
./devicetester_linux run-suite --suite-id GGV2Q_1.0.0 --pool-id DevicePool1 --timeout-multiplier 2.5
```

Para obter mais informações, execute `run-suite --help`.

Alguns erros de tempo limite ocorrem quando os casos de teste do IDT não podem ser concluídos devido a problemas de configuração. Você não pode resolver esses erros aumentando o multiplicador de tempo limite. Use os logs da execução do teste para solucionar os problemas de configuração subjacentes. 
+ Se os logs do componente MQTT ou Lambda `Access denied` contiverem erros, sua pasta de instalação do Greengrass pode não ter as permissões de arquivo corretas. Execute o comando a seguir para cada pasta no caminho de instalação que você definiu em seu arquivo `userdata.json`. 

  ```
  sudo chmod 755 folder-name
  ```
+ Se os logs do Greengrass indicarem que a implantação da CLI do Greengrass não foi concluída, faça o seguinte:
  + Verifique se `bash` está instalado no dispositivo em teste. 
  + Se o arquivo `userdata.json` incluir o parâmetro de configuração `GreengrassCliVersion`, remova-o. Esse parâmetro está obsoleto no IDT v4.1.0 e versões posteriores. Para obter mais informações, consulte [Configurar o userdata.json](set-config.md#userdata-config).
+ Se o teste de implantação do Lambda falhar com uma mensagem de erro de “Validando a publicação do Lambda: tempo limite” e você receber um erro no arquivo de log de teste (`idt-gg2-lambda-function-idt-<resource-id>.log`) que diz `Error: Could not find or load main class com.amazonaws.greengrass.runtime.LambdaRuntime.`, faça o seguinte:
  + Verifique para qual pasta foi usada para `InstallationDirRootOnDevice` no arquivo `userdata.json`.
  + Verifique se as permissões de usuário corretas estão configuradas no seu dispositivo. Para obter mais detalhes, consulte [Configurar permissões de usuário em seu dispositivo](https://docs.aws.amazon.com/greengrass/v2/developerguide/device-config-setup.html#root-access).

### Erros de verificação de versão
<a name="version-compatibility-check-failure"></a>

O IDT emite o seguinte erro quando as credenciais AWS do usuário do IDT não têm as permissões necessárias do IAM. 

```
Failed to check version compatibility
```

O AWS usuário que não tem as permissões necessárias do IAM. 