¿Cómo soluciono los problemas de una instancia de Amazon EC2 que se detiene o termina cuando intento iniciarla con los errores «InternalError» o «Client.UserInitiatedShutdown»?

9 minutos de lectura
0

Cuando intento iniciar mi instancia de Amazon Elastic Compute Cloud (Amazon EC2), termina o no se inicia y recibo el error «InternalError» o «Client.UserInitiatedShutdown».

Breve descripción

Las siguientes causas son las comunes de un error «InternalError» o un error «Client.UserInitiatedShutdown» de una instancia de Amazon EC2:

  • Su volumen de Amazon Elastic Block Store (Amazon EBS) no está conectado correctamente a la instancia.
  • Un volumen de EBS conectado a la instancia se encuentra en estado de error.
  • Se ha conectado un volumen de EBS cifrado a la instancia y la entidad no tiene permisos para la clave de AWS Key Management Service (AWS KMS).
  • Una instancia de Amazon EC2 se detuvo unos minutos después de que se iniciara debido a una interrupción del sistema operativo, como el daemon de auditoría.

Nota:

Resolución

Los volúmenes de EBS no están conectados correctamente a la instancia

Debe conectar el volumen raíz de EBS a la instancia como /dev/sda1 o /dev/xvda, según cuál esté definido en la API. No puede tener un segundo volumen de EBS con un nombre de dispositivo duplicado o un nombre conflictivo. Cuando esto ocurre, no se puede detener ni iniciar la instancia. Los conflictos de nombres de dispositivos de bloque afectan solo a los tipos de instancias basados en Xen (c4, m4, t2, etc.). Bloquear conflictos entre nombres de dispositivos no afecta a las instancias basadas en Nitro (c5, m5, t3, etc.).

  1. Para comprobar el mensaje de error StateReason y el código de error, ejecute la API describe-instances:

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

    Nota: Sustituya us-east-1 por su región de AWS. Sustituya i-nnnnnnnnnnnnnnn por el ID de su instancia.

    Si hay un conflicto con el nombre del dispositivo, aparecerá un resultado similar al siguiente mensaje:

    [    [{
            "StateReason": {
                "Code": "Server.InternalError",
                "Message": "Server.InternalError: Internal error on launch"
            }
        }]
    ]
  2. Abra la consola de Amazon EC2 y, a continuación, seleccione la instancia que no puede iniciar.

  3. En la pestaña Descripción, compruebe el nombre del dispositivo que aparece en dispositivos de bloques. El campo dispositivos de bloques muestra todos los nombres de los dispositivos de los volúmenes conectados.

  4. Compruebe que el dispositivo raíz esté conectado correctamente y que no aparezca ningún dispositivo con el mismo nombre o con un nombre conflictivo.

  5. Si hay un dispositivo con un duplicado o un nombre de dispositivo conflictivo, primero separe el volumen y cámbiale el nombre. A continuación, vuelva a conectar el volumen con el nombre de dispositivo actualizado.

Un volumen de EBS conectado se encuentra en estado de error

  1. Ejecute la API describe-instances para comprobar el mensaje de error StateReason y el código de error:

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

    Nota: Sustituya us-east-1 por su región de AWS. Sustituya i-nnnnnnnnnnnnnnn por el ID de su instancia.

    Si hay un volumen de EBS conectado que se encuentra en estado de error, aparecerá un resultado similar al siguiente mensaje:

    [    [{
            "StateReason": {
                "Code": "Server.InternalError",
                "Message": "Server.InternalError: Internal error on launch"
            }
        }]
    ]
  2. Abra la consola de Amazon EC2, seleccione Volúmenes y compruebe si el estado del volumen es error. Las opciones varían en función de si el volumen es un volumen raíz o un volumen secundario.

  3. Si el volumen que está en estado de error es un volumen secundario, separe el volumen y, a continuación, inicie la instancia.

  4. Si el volumen que está en estado de error es un volumen raíz y tiene una instantánea del volumen, siga estos pasos:
    Desconecte el volumen.
    Cree un volumen nuevo a partir de la instantánea.
    Use el nombre de dispositivo de la instancia original para conectar el volumen nuevo y, a continuación, inicie la instancia.

Nota: Si no tiene una instantánea del volumen raíz que esté en estado de error, no podrá reiniciar la instancia. Debe lanzar una nueva instancia, instalar las aplicaciones pertinentes y, a continuación, configurar la nueva instancia para reemplazar la instancia anterior.

Los volúmenes de EBS conectados están cifrados y los permisos de IAM para acceder a las claves de AWS KMS son insuficientes

Para resolver este problema, siga estos pasos para comprobar los permisos de AWS Identity and Access Management (IAM).

  1. Ejecute la API describe-instances para comprobar el mensaje de error StateReason y el código de error:

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

    Nota: Sustituya us-east-1 por su región de AWS. Sustituya i-nnnnnnnnnnnnnnn por el ID de su instancia.

    Si hay un volumen cifrado conectado a la instancia y hay problemas de permisos o políticas, recibirá un error de cliente. Esto devuelve un resultado similar al siguiente mensaje:

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

Compruebe que el usuario que ha intentado iniciar la instancia tenga los permisos de IAM correctos. Si lanzó la instancia de forma indirecta a través de otro servicio, como EC2 Auto Scaling, compruebe también las siguientes configuraciones:

Nota: Para comprobar si un volumen está cifrado, abra la consola de Amazon EC2 y, a continuación, seleccione Volúmenes. Los volúmenes cifrados muestran la etiqueta Cifrado en la columna Cifrado.

Cierre de la instancia de EC2 debido a interrupciones del sistema operativo, como el daemon de auditoría

Verifique el código de error de la causa del cierre de la instancia de EC2. Si la instancia de EC2 se cierra debido a un error del sistema operativo, como «Client.UserInitiatedShutdown», cree una instancia de rescate. Siga estos pasos para solucionar el problema.

Verifique la causa del cierre de la instancia de EC2

Para verificar por qué se cerró la instancia de EC2, ejecute el siguiente comando:

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

Resultado del ejemplo:

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

**Nota:**Se recomienda iniciar el cierre desde el nivel del sistema operativo.

Crear una instancia de rescate

Siga estos pasos para crear una instancia de rescate. Dado que la instancia está detenida, debe tener la instancia de rescate para acceder a los parámetros en auditd.conf.

  1. Abra la consola de Amazon EC2.

  2. Elija Instancias en el panel de navegación y, a continuación, seleccione la instancia deteriorada.

  3. Detenga la instancia.

  4. Desconecte el volumen /dev/xvda de Amazon EBS de la instancia detenida.

  5. Inicie una nueva instancia de EC2 en la misma zona de disponibilidad que la instancia deteriorada. La nueva instancia se convierte en su instancia de rescate.

  6. Conecte el volumen de Amazon EBS que desconectó en el paso 4 a la instancia de rescate como dispositivo secundario.

  7. Use SSH para conectarse a su instancia de rescate.

  8. Monte el volumen en /mnt con el siguiente comando:

    $ sudo mount /dev/xvdf /mnt/

    **Nota:**Si el directorio /mnt/var/log está vacío o falta, compruebe que la entrada /mnt/etc/fstab existe. A continuación, monte la partición requerida para /var/log o /var/log/audit siguiendo el paso 8.

Verifique los registros a nivel del sistema operativo

Para verificar los registros a nivel del sistema operativo del daemon de auditoría, ejecute los siguientes comandos:

Sistemas operativos basados en RPM:

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

Sistemas operativos basados en Debian:

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

El siguiente resultado indica que el espacio en disco es bajo para el daemon de auditoría y que la instancia está detenida:

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

Por lo general, se monta una partición diferente para /var/log o /var/log/audit y estas particiones se llenan mientras la partición raíz está libre de espacio en disco. En este escenario, no se produce el error «No queda espacio en el dispositivo», pero la instancia no se inicia.

Verificar el espacio en disco

Para comprobar el espacio en disco, ejecute el siguiente comando:

> df -hT

Comprobar los parámetros de acción del daemon de auditoría

Si el espacio en disco está lleno, compruebe la acción del daemon de auditoría en /etc/auditd/auditd.conf para ver los siguientes parámetros:

admin_space_left

Este valor define el valor mínimo en megabytes del disco libre para que el daemon de auditoría realice una acción en caso de que haya poco espacio en disco.

admin_space_left_action

Este parámetro define la acción que el daemon de auditoría realiza cuando hay poco espacio en disco. Los valores válidos son ignore, syslog, rotate, email, exec, suspend, single y halt.

Tras cambiar la acción del daemon de auditoría, vuelva a conectar el volumen de Amazon EBS a la instancia como /dev/sda1 y, a continuación, inicie la instancia.

Para obtener más información sobre cómo cambiar estos parámetros, consulte auditd.conf en el sitio web de man7.

**Nota:**También puede aumentar el tamaño de la partición del volumen de Amazon EBS.

Información relacionada

¿Por qué no puedo iniciar ni lanzar mi instancia de EC2?

Key policies in AWS KMS

La instancia termina inmediatamente

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 10 meses