Linux: controlli rapidi quando il server non risponde al boot

Quando il problema compare solo dopo il reboot

Un server Linux può funzionare bene per giorni e poi smettere di rispondere subito dopo un riavvio. In questi casi conviene seguire una sequenza di controlli rapidi, per capire se il blocco riguarda il boot, la rete, i mount, systemd o una risorsa esaurita.

L’obiettivo è arrivare presto al punto critico, senza perdere tempo su sintomi secondari.

1. Verifica se il sistema è davvero arrivato al login

Se hai accesso alla console, controlla prima di tutto se il sistema ha completato l’avvio.

systemctl is-system-running

Se il risultato non è running o degraded, il problema è probabilmente nel boot o in un servizio bloccante.

Per vedere gli errori più recenti:

journalctl -b -p err

Se il server si ferma su un messaggio specifico, spesso hai già la causa in mano.

2. Controlla i mount che possono bloccare l’avvio

Un disco esterno, un volume LVM, un NFS o una partizione con UUID cambiato può rallentare o fermare l’avvio.

findmnt -a

systemctl --failed

Se trovi un mount fallito, verifica /etc/fstab e aggiungi opzioni più tolleranti quando serve, ad esempio nofail o un timeout più adatto.

Un mount remoto non disponibile può trasformarsi in un problema di boot, non solo di storage.

3. Verifica rete, DNS e interfacce

Se il server parte ma non è raggiungibile, controlla che l’interfaccia abbia preso IP e route corrette.

ip a

ip route

resolvectl status

Su sistemi con NetworkManager o systemd-networkd, un profilo errato può lasciare la macchina “accesa ma invisibile”.

Controlla anche che il servizio di rete sia attivo:

systemctl status NetworkManager

oppure:

systemctl status systemd-networkd

4. Cerca servizi in errore o in attesa

Un singolo servizio può impedire l’uso normale del sistema, soprattutto se dipende da storage, rete o permessi.

systemctl --failed

journalctl -u nome-servizio -b

Se un’unità va in loop, guarda se il problema è un file mancante, una variabile d’ambiente errata o un percorso non più valido dopo il reboot.

5. Controlla spazio disco, inode e memoria

Molti blocchi dopo l’avvio sono causati da risorse esaurite.

df -h

df -i

free -h

Se la root è piena, systemd e i servizi possono fallire in modi poco evidenti. Anche gli inode esauriti possono dare l’impressione di un sistema “rotto” pur avendo ancora spazio libero.

6. Guarda i log del kernel

Se il problema è hardware, driver o filesystem, il kernel spesso lascia indizi chiari.

dmesg -T | tail -n 100

Messaggi come I/O error, filesystem in sola lettura o device non trovato indicano un guasto più profondo rispetto a un semplice servizio mal configurato.

7. Verifica permessi, SELinux o AppArmor

Dopo un riavvio, un servizio può fallire perché non riesce ad accedere a un file, a una directory o a una porta protetta.

Controlla i log e, se usi SELinux o AppArmor, verifica eventuali blocchi di sicurezza.

getenforce

aa-status

Se il servizio funziona solo disattivando temporaneamente il controllo, la causa è quasi sempre una policy da correggere, non da aggirare.

8. Valuta i problemi legati al boot loader

Se il server non arriva nemmeno al sistema operativo, il problema può essere nel boot loader, nel kernel o nella configurazione della partizione di avvio.

In questi casi verifica:

• ordine di boot nel firmware
• presenza del disco corretto
• integrità della partizione EFI o /boot
• kernel avviato di recente dopo un aggiornamento

Un aggiornamento incompleto o un kernel non avviabile può lasciare il sistema fermo prima ancora di caricare i servizi.

9. Fai un controllo rapido dei job avviati all’accesso

A volte il server sembra bloccato, ma in realtà attende script o operazioni lanciate all’avvio.

systemctl list-jobs

Se trovi job in attesa per troppo tempo, individua l’unità che li sta trattenendo e verifica dipendenze, timeout e retry.

10. Tieni pronta una mini-sequenza di diagnosi

Quando il tempo è poco, questa sequenza copre i casi più frequenti:

1. systemctl is-system-running
2. systemctl --failed
3. journalctl -b -p err
4. df -h e df -i
5. ip a e ip route
6. dmesg -T | tail -n 100

Se il guasto non emerge subito, hai comunque ristretto il campo a boot, rete, storage o servizi.

Conclusione

Quando un server Linux non risponde dopo il riavvio, la chiave è distinguere rapidamente tra problemi di avvio, mount, rete e risorse. Una checklist corta ma ordinata evita tentativi casuali e porta più in fretta alla causa reale.

Se vuoi, posso anche scrivere una versione più tecnica, una più orientata a sysadmin o una checklist specifica per Ubuntu, Debian, RHEL o AlmaLinux.