Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
Come faccio a risolvere un'istanza Amazon EC2 che si arresta o termina quando provo ad avviarla con l'errore "InternalError" o "Client.UserInitiatedShutdown"?
Quando provo ad avviare l'istanza Amazon Elastic Compute Cloud (Amazon EC2), termina o non si avvia; inoltre ricevo l'errore “InternalError” o “Client.UserInitiatedShutdown”.
Descrizione breve
I seguenti motivi sono cause comuni dell'errore “InternalError” o “Client.UserInitiatedShutdown” di un'istanza Amazon EC2:
- Il tuo volume Amazon Elastic Block Store (Amazon EBS) non è collegato correttamente all'istanza.
- Un volume EBS collegato all'istanza presenta uno stato di errore.
- Un volume EBS crittografato è collegato all'istanza e l'entità non dispone delle autorizzazioni per la chiave Servizio AWS di gestione delle chiavi (AWS KMS).
- Un'istanza Amazon EC2 è stata interrotta pochi minuti dopo il suo avvio a causa di un'interruzione del sistema operativo, ad esempio il daemon di controllo.
Nota:
- se l'istanza non si avvia e non viene visualizzato alcun codice di errore, esegui il comando describe-instances nell’Interfaccia della linea di comando AWS (AWS CLI). Quindi controlla il messaggio StateReason che il comando restituisce nella risposta JSON.
- Se visualizzi dei messaggi di errore quando esegui i comandi dell'interfaccia AWS CLI, consulta la sezione Troubleshoot AWS CLI errors. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.
Soluzione
I volumi EBS non sono collegati correttamente all'istanza
È necessario collegare il volume root EBS all'istanza come /dev/sda1 o /dev/xvda, a seconda di quale fra i due è definito nell'API. Non puoi avere un secondo volume EBS con un nome di dispositivo duplicato o un nome in conflitto. Quando accade, non puoi interrompere o avviare l'istanza. I conflitti tra i nomi dei dispositivi a blocchi riguardano solo i tipi di istanze basati su Xen (c4, m4, t2 e così via). I conflitti tra i nomi dei dispositivi a blocchi non influiscono sulle istanze basate su Nitro (c5, m5, t3 e così via).
-
Per verificare il messaggio di errore StateReason e il codice di errore, esegui l'API describe-instances:
$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json
Nota: sostituisci us-east-1 con la tua Regione AWS. Sostituisci i-nnnnnnnnnnnnnnnnn con il tuo ID istanza.
Se è presente un conflitto tra i nomi dei dispositivi, viene visualizzato un output simile al seguente messaggio:
[ [{ "StateReason": { "Code": "Server.InternalError", "Message": "Server.InternalError: Internal error on launch" } }] ]
-
Apri la console Amazon EC2, quindi seleziona l'istanza che non riesci ad avviare.
-
Nella scheda Descrizione, verifica il nome del dispositivo elencato in Blocca dispositivi. Il campo Blocca dispositivi mostra tutti i nomi dei dispositivi dei volumi allegati.
-
Verifica che il dispositivo root sia collegato correttamente e che non sia elencato un dispositivo con lo stesso nome o con un nome in conflitto.
-
Se c'è un dispositivo con un duplicato o il nome del dispositivo è in conflitto, scollega prima il volume e rinominalo. Quindi, ricollega il volume con il nome del dispositivo aggiornato.
Un volume EBS collegato si trova in uno stato di errore
-
Esegui l'API describe-instances per verificare il messaggio di errore StateReason e il codice di errore:
$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json
Nota: sostituisci us-east-1 con la tua Regione AWS. Sostituisci i-nnnnnnnnnnnnnnnnn con il tuo ID istanza.
Se è presente un volume EBS allegato in stato di errore, viene visualizzato un output simile al seguente messaggio:
[ [{ "StateReason": { "Code": "Server.InternalError", "Message": "Server.InternalError: Internal error on launch" } }] ]
-
Apri la console Amazon EC2, scegli Volumi e verifica se lo stato del volume è un errore. Le opzioni disponibili variano a seconda che si tratti di un volume principale o secondario.
-
Se il volume in stato di errore è un volume secondario, scollega il volume e avvia l'istanza.
-
Se il volume in stato di errore è un volume root e disponi di un'istantanea del volume, completa i seguenti passaggi:
Scollega il volume.
Crea un nuovo volume dall'istantanea.
Usa il nome del dispositivo dell'istanza originale per collegare il nuovo volume, quindi avvia l'istanza.
Nota: se non disponi di un'istantanea esistente del volume root in stato di errore, non puoi riavviare l'istanza. È necessario avviare una nuova istanza, installare le applicazioni pertinenti e quindi configurarla per sostituire la vecchia istanza.
I volumi EBS collegati sono crittografati e le autorizzazioni IAM per accedere alle chiavi AWS KMS sono insufficienti
Per risolvere il problema segui questi passaggi in modo da verificare le autorizzazioni AWS Identity and Access Management (IAM).
-
Esegui l'API describe-instances per verificare il messaggio di errore StateReason e il codice di errore:
$ aws ec2 describe-instances --instance-id i-nnnnnnnnnnnnnnn --region us-east-1 --query "Reservations[].Instances[].{StateReason:StateReason}" --output json
Nota: sostituisci us-east-1 con la tua Regione AWS. Sostituisci i-nnnnnnnnnnnnnnnnn con il tuo ID istanza.
Se è presente un volume crittografato collegato all'istanza e ci sono problemi con le autorizzazioni o le policy, viene visualizzato un errore del client. Ciò restituisce un output simile al seguente messaggio:
[ [{ "StateReason": { "Code": "Client.InternalError", "Message": "Client.InternalError: Client error on launch" } }] ]
Verifica se l'utente che ha tentato di avviare l'istanza dispone delle autorizzazioni IAM corrette. Se hai avviato l'istanza indirettamente tramite un altro servizio, ad esempio EC2 Auto Scaling, verifica anche le seguenti configurazioni:
- La chiave AWS KMS utilizzata per crittografare il volume viene attivata.
- La chiave presenta policy della chiave corrette.
Nota: per verificare se un volume è crittografato, apri la console Amazon EC2 e seleziona Volumi. I volumi crittografati mostrano l'etichetta Crittografato nella colonna Crittografia.
Arresto dell'istanza EC2 a causa di interruzioni del sistema operativo come il daemon di audit
Verifica il codice di errore che indica il motivo dell'arresto dell'istanza EC2. Se l'istanza EC2 viene chiusa a causa di un errore del sistema operativo come “client.userInitiatedShutdown”, crea un'istanza di ripristino. Segui questi passaggi per la risoluzione dei problemi.
Verificare il motivo dell'arresto dell'istanza EC2
Per verificare il motivo per cui l'istanza EC2 si è chiusa, esegui il comando seguente:
aws ec2 describe-instances --instance-ids i-xxxx --query 'Reservations[*].Instances[].StateReason'
Esempio di output:
[ { "Code": "Client.UserInitiatedShutdown", "Message": "Client.UserInitiatedShutdown: User initiated shutdown" } ]
Nota: è consigliabile avviare l'arresto a livello di sistema operativo.
Creare un'istanza di ripristino
Segui questi passaggi per creare un'istanza di ripristino. Poiché l'istanza è interrotta, è necessario disporre dell'istanza di ripristino per accedere ai parametri in auditd.conf.
-
Apri la console Amazon EC2.
-
Scegli Istanze dal riquadro di navigazione, quindi scegli l'istanza compromessa.
-
Scollega il volume Amazon EBS /dev/xvda dall'istanza interrotta.
-
Avvia una nuova istanza EC2 nella stessa zona di disponibilità dell'istanza compromessa. La nuova istanza diventerà la tua istanza di ripristino.
-
Collega il volume Amazon EBS che hai scollegato nel passaggio 4 all'istanza di ripristino come dispositivo secondario.
-
Monta il volume in /mnt con il seguente comando:
$ sudo mount /dev/xvdf /mnt/
Nota: se la directory /mnt/var/log è vuota o se manca, verifica che esista la voce /mnt/etc/fstab. Quindi monta la partizione richiesta per /var/log o /var/log/audit seguendo il passaggio 8.
Verificare i log a livello di sistema operativo
Per verificare i log a livello di sistema operativo in relazione al daemon di audit, esegui i seguenti comandi:
Sistemi operativi basati su RPM:
> cat /var/log/messages | grep -i "Audit daemon"
Sistemi operativi basati su Debian:
> cat /var/log/syslog | grep -i "Audit daemon"
L'output seguente indica che lo spazio su disco è insufficiente per il demone di audit e che l'istanza è stata interrotta:
auditd[1009]: Audit daemon is low on disk space for logging auditd[1009]: The audit daemon is now halting the system
Di solito viene montata una partizione diversa per /var/log o /var/log/audit; queste partizioni si riempiono mentre la partizione root è libera da spazio su disco. In questo scenario, l'errore "No space left on device" non si verifica, ma l'istanza non si avvia.
Verificare lo spazio su disco
Per verificare lo spazio su disco, esegui il comando seguente:
> df -hT
Controllare i parametri di azione del daemon di audit
Se lo spazio su disco è pieno, controlla l'azione del daemon di audit in /etc/auditd/auditd.conf per i seguenti parametri:
admin_space_left
Questo valore definisce il valore minimo in megabyte per il disco libero, affinché il daemon di audit esegua un'azione in caso di spazio su disco insufficiente.
admin_space_left_action
Questo parametro definisce l'azione che il daemon di audit esegue quando lo spazio su disco è insufficiente. I valori validi sono ignore, syslog, rotate, email, exec, suspend, single e halt.
Dopo aver modificato l'azione del daemon di audit, ricollega il volume Amazon EBS all'istanza come /dev/sda1, quindi avvia l'istanza.
Per ulteriori informazioni su come modificare questi parametri, consulta auditd.conf sul sito web man7.
Nota: puoi anche aumentare la dimensione della partizione del volume Amazon EBS.
Informazioni correlate

Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 2 anni fa