Como soluciono problemas de uma instância do Amazon EC2 que é interrompida ou encerrada quando tento iniciá-la com o erro “InternalError” ou “Client.UserInitiatedShutdown”?

Breve descrição

Os motivos a seguir são as causas comuns do erro “InternalError” ou “Client.UserInitiatedShutdown” de uma instância do Amazon EC2:

• Seu volume do Amazon Elastic Block Store (Amazon EBS) não está anexado à instância corretamente.
• Um volume do EBS anexado à instância está em estado de erro.
• Um volume criptografado do EBS é anexado à instância e a entidade não tem permissões para a chave do AWS Key Management Service (AWS KMS).
• Uma instância do Amazon EC2 foi interrompida alguns minutos depois de ser iniciada por uma interrupção do sistema operacional, como o daemon de auditoria.

Observação:

• se sua instância não iniciar e nenhum código de erro aparecer, execute o comando describe-instances na AWS Command Line Interface (AWS CLI). Em seguida, verifique a mensagem StateReason que o comando retorna na resposta JSON.
• Se você receber erros ao executar comandos da AWS CLI, consulte Solucionar erros da AWS CLI. Além disso, verifique se está usando a versão mais recente da AWS CLI.

Resolução

Os volumes do EBS não estão anexados à instância corretamente

Você deve anexar o volume raiz do EBS à instância como /dev/sda1 ou /dev/xvda, com base em qual deles está definido na API. Você não pode ter um segundo volume do EBS com um nome de dispositivo duplicado ou um nome em conflito. Quando isso acontece, não poderá interromper ou iniciar a instância. Os conflitos de nomes de dispositivos de blocos afetam somente os tipos de instância baseados em Xen (c4, m4, t2 e assim por diante). Conflitos de nomes de dispositivos de blocos não afetam as instâncias baseadas em Nitro (c5, m5, t3 e assim por diante).

1. Para verificar a mensagem de erro StateReason e o código de erro, execute a API describe-instances:

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   Observação: substitua us-east-1 pela sua região da AWS. Substitua i-nnnnnnnnnnnnnnn pelo ID da sua instância.

   Se houver um conflito de nome de dispositivo, você verá uma saída semelhante à seguinte mensagem:

   [    [{
           "StateReason": {
               "Code": "Server.InternalError",
               "Message": "Server.InternalError: Internal error on launch"
           }
       }]
   ]

2. Abra o console do Amazon EC2 e selecione a instância que você não consegue iniciar.

3. Na guia Descrição, verifique o nome do dispositivo que é listado em Dispositivos de blocos. O campo Dispositivos de blocos exibe todos os nomes de dispositivos dos volumes anexados.

4. Verifique se o dispositivo raiz está anexado corretamente e se não há nenhum dispositivo listado com o mesmo nome ou com um nome conflitante.

5. Se houver um dispositivo com um nome de dispositivo duplicado ou conflitante, primeiro desconecte o volume e renomeie-o. Em seguida, reanexe o volume com o nome do dispositivo atualizado.

Um volume do EBS anexado está em um estado de erro

1. Execute a API describe-instances para verificar a mensagem de erro StateReason e o código de erro:

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   Observação: substitua us-east-1 pela sua região da AWS. Substitua i-nnnnnnnnnnnnnnn pelo ID da sua instância.

   Se houver um volume do EBS anexado que esteja em estado de erro, você verá uma saída semelhante à seguinte mensagem:

   [    [{
           "StateReason": {
               "Code": "Server.InternalError",
               "Message": "Server.InternalError: Internal error on launch"
           }
       }]
   ]

2. Abra o console do Amazon EC2, escolha Volumes e verifique se o status do volume é erro. Suas opções variam se o volume é raiz ou secundário.

3. Se o volume que está em estado de erro for um volume secundário, desanexe o volume e inicie a instância.

4. Se o volume que está em estado de erro for um volume raiz e você tiver um snapshot do volume, conclua as seguintes etapas:
   Desanexe o volume.
   Crie um novo volume a partir do snapshot.
   Use o nome do dispositivo da instância original para anexar o novo volume e, em seguida, inicie a instância.

Observação: se você não tiver um snapshot existente do volume raiz que esteja em estado de erro, não poderá reiniciar a instância. Você deve iniciar uma nova instância, instalar os aplicativos relevantes e, em seguida, configurá-la para substituir a instância antiga.

Os volumes do EBS anexados são criptografados e as permissões do IAM para acessar as chaves do AWS KMS são insuficientes

Para resolver esse problema, siga estas etapas para verificar as permissões do AWS Identity and Access Management (IAM).

1. Execute a API describe-instances para verificar a mensagem de erro StateReason e o código de erro:

   $ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json

   Observação: substitua us-east-1 pela sua região da AWS. Substitua i-nnnnnnnnnnnnnnn pelo ID da sua instância.

   Se houver um volume criptografado anexado à instância e houver problemas de permissões ou políticas, você receberá um erro de cliente. Isso retorna uma saída semelhante à seguinte mensagem:

   [    [{
           "StateReason": {
               "Code": "Client.InternalError",
               "Message": "Client.InternalError: Client error on launch"
           }
       }]
   ]

Verifique se o usuário que tentou iniciar a instância tem as permissões do IAM corretas. Se você executou a instância indiretamente por meio de outro serviço, como o EC2 Auto Scaling, verifique também as seguintes configurações:

• A chave do AWS KMS usada para criptografar o volume é ativada.
• A chave tem as políticas de chave corretas.

Observação: para verificar se um volume está criptografado, abra o console do Amazon EC2 e selecione Volumes. Os volumes criptografados mostram o rótulo Criptografado na coluna Criptografia.

Desligamento da instância EC2 devido a interrupções no sistema operacional, como o daemon de auditoria

Verifique o código de erro do motivo do desligamento da instância EC2. Se a instância do EC2 for encerrada devido a um erro do sistema operacional, como “Client.UserInitiatedShutdown”, crie uma instância de recuperação. Em seguida, siga estas etapas de solução de problemas.

Verificar o motivo do desligamento da instância EC2

Para verificar por que a instância do EC2 foi encerrada, execute o seguinte comando:

aws ec2 describe-instances --instance-ids i-xxxx --query 'Reservations[*].Instances[].StateReason'

Exemplo de saída:

[
    {
        "Code": "Client.UserInitiatedShutdown",
        "Message": "Client.UserInitiatedShutdown: User initiated shutdown"
    }
]

Observação: é uma prática recomendada iniciar o desligamento a partir do nível do sistema operacional.

Criar uma instância de resgate

Siga essas etapas para criar uma instância de resgate. Como a instância está interrompida, você precisa ter a instância de resgate para acessar os parâmetros em auditd.conf.

1. Abra o console do Amazon EC2.

2. Escolha Instâncias no painel de navegação e selecione a instância danificada.

3. Interrompa a instância.

4. Desassocie o volume /dev/xvda do Amazon EBS da instância interrompida.

5. Execute uma nova instância do EC2 na mesma zona de disponibilidade da instância danificada. A nova instância se torna sua instância de resgate.

6. Anexe o volume do Amazon EBS que você separou na etapa 4 à instância de resgate como um dispositivo secundário.

7. Use o SSH para se conectar à sua instância de resgate.

8. Monte o volume em /mnt com o seguinte comando:

   $ sudo mount /dev/xvdf /mnt/

   Observação: se o diretório /mnt/var/log estiver vazio ou ausente, verifique se a entrada /mnt/etc/fstab existe. Em seguida, monte a partição necessária para /var/log ou /var/log/audit seguindo a etapa 8.

Verificar os logs no nível do sistema operacional

para verificar os registros no nível do sistema operacional para o daemon de auditoria, execute os seguintes comandos:

Sistemas operacionais baseados em RPM:

> cat /var/log/messages | grep -i "Audit daemon"

Sistemas operacionais baseados em Debian:

> cat /var/log/syslog | grep -i "Audit daemon"

A saída a seguir indica que o espaço em disco está baixo para o daemon de auditoria e que a instância está parada:

auditd[1009]: Audit daemon is low on disk space for logging
auditd[1009]: The audit daemon is now halting the system

Normalmente, uma partição diferente é montada para /var/log ou /var/log/audit, e essas partições ficam cheias enquanto a partição raiz está livre de espaço em disco. Nesse cenário, o erro “Não há espaço restante no dispositivo” não ocorre, mas a instância não é inicializada.

**Verificar o espaço em disco **

Para verificar o espaço em disco, execute o seguinte comando:

> df -hT

Verificar os parâmetros de ação do daemon de auditoria

Se o espaço em disco estiver cheio, verifique a ação do daemon de auditoria em /etc/auditd/auditd.conf para obter os seguintes parâmetros:

admin_space_left

Esse valor define o valor mínimo em megabytes de disco livre para que o daemon de auditoria execute uma ação com pouco espaço em disco.

admin_space_left_action

Esse parâmetro define a ação que o daemon de auditoria executa quando o espaço em disco está baixo. Os valores válidos são ignore, syslog, rotate, email, exec, suspend, single e halt.

Depois de alterar a ação do daemon de auditoria, conecte o volume do Amazon EBS de volta à instância como /dev/sda1 e inicie a instância.

Para obter mais informações sobre como alterar esses parâmetros, consulte auditd.conf no site man7.

Observação: você também pode aumentar o tamanho da partição de volume do Amazon EBS.

Informações relacionadas

Por que não consigo iniciar ou executar minha instância do EC2?

Principais políticas no AWS KMS

A instância é encerrada imediatamente