Chi lavora con Linux da anni conosce bene quella sensazione: un errore inaspettato blocca il server, un servizio smette di rispondere, un sistema che ieri funzionava perfettamente oggi presenta comportamenti anomali. La differenza tra un amministratore di sistema esperto e uno alle prime armi non sta tanto nella conoscenza enciclopedica dei comandi, quanto nell’adozione di un metodo sistematico di analisi.
In questo articolo descriviamo un approccio in quattro passi che consente di affrontare con metodo qualsiasi errore su Linux, riducendo drasticamente i tempi di risoluzione e gli errori per tentativi.
Il principio fondamentale: metodo prima di tutto
Il troubleshooting efficace non è una questione di fortuna o di esperienza accumulata a caso. È una disciplina che richiede di rallentare, osservare e procedere un passo alla volta. La tentazione più comune è quella di applicare subito la prima soluzione trovata online, modificando più variabili contemporaneamente. Questo approccio porta quasi sempre a peggiorare la situazione o, nella migliore delle ipotesi, a non capire quale modifica ha effettivamente risolto il problema.
Passo 1: raccogliere indizi e definire il problema con precisione
Il punto di partenza è una definizione precisa del problema. “Il server non funziona” è inutile ai fini diagnostici. “Il web server restituisce un 503 su /api/users dopo il deploy delle 14:30″ è un punto di partenza solido.
Le domande da porsi immediatamente sono:
- Quando si è manifestato il problema per la prima volta?
- Cosa è cambiato recentemente? (aggiornamento pacchetti, modifica configurazione, riavvio)
- Il problema è riproducibile? In quali condizioni?
- Qual è esattamente il messaggio di errore?
Un consiglio pratico spesso sottovalutato: se un’applicazione non si avvia correttamente, chiudete l’interfaccia grafica e lanciatela da terminale. La maggior parte delle applicazioni stampa i messaggi di errore sullo standard output o standard error, fornendo clue preziosi che l’interfaccia nasconde.
Catturate sempre l’output esatto dell’errore. Un kernel panic al boot, un prompt GRUB rescue, o un messaggio “device not found” contengono già le informazioni necessarie per risolvere il problema.
Passo 2: analizzare lo stato del sistema e i log
Con il problema definito, è il momento di esaminare lo stato corrente del sistema. Questa fase si divide in due parti: lo stato delle risorse e l’analisi dei log.
Stato delle risorse
Verificate se CPU, memoria, disco e rete sono in condizioni normali:
# CPU e memoria
top
htop
# Spazio disco
df -h
du -sh /var/log/* | sort -rh | head -20
# Rete
ip a
ip route
ping -c 4 8.8.8.8
Analisi dei log
Linux mette a disposizione strumenti potenti per l’analisi dei log. Con systemd, il comando principale è journalctl:
# Log del boot corrente con dettagli errori
journalctl -xb
# Log di un servizio specifico (es. nginx)
journalctl -u nginx --since "1 hour ago"
# Seguire i log in tempo reale
journalctl -f
# Filtrare solo gli errori
journalctl -p err -b
Per i sistemi che usano ancora i log tradizionali:
# Syslog generale
grep -i error /var/log/syslog | tail -50
# Log kernel
dmesg | grep -i "error\|fail\|warn" | tail -30
# Ricerca per intervallo temporale
journalctl --since "2026-06-22 14:00" --until "2026-06-22 15:00"
Non è necessario comprendere ogni singola riga dei log. L’obiettivo è identificare parole chiave come error, failed, segfault, permission denied, o il nome del servizio problematico nelle righe temporalmente vicine all’evento.
Passo 3: formulare ipotesi e testare una variabile alla volta
Con i dati raccolti nei passi precedenti, è il momento dell’analisi. Basandosi sui sintomi, sui cambiamenti recenti e sui log, si formula un’ipotesi sulla causa del problema.
Alcune regole pratiche:
- Un segmentation fault → sospettare corruzione della memoria o libreria incompatibile
- “Permission denied” → verificare permessi file, SELinux/AppArmor, ACL
- “Device not found” al boot → UUID del disco modificato dopo aggiornamento o sostituzione
- Servizio che crasha dopo un aggiornamento → provare il rollback del pacchetto
La regola d’oro è modificare una variabile alla volta. Se sospettate che un aggiornamento del pacchetto abbia causato il problema, fate il downgrade su un sistema di test prima di applicarlo in produzione. Questo permette di isolare la causa con certezza.
# Rollback di un pacchetto su Debian/Ubuntu
apt-cache showpkg nginx
apt-get install nginx=1.24.0-2
# Su RHEL/Rocky Linux
dnf downgrade nginx
# Verificare i file di configurazione con sintassi check
nginx -t
systemd-analyze verify /etc/systemd/system/myservice.service
La ricerca online è un validissimo alleato: incollare il messaggio di errore esatto in un motore di ricerca, nella documentazione ufficiale della distro, o in un AI assistant porta quasi sempre a soluzioni già documentate.
Passo 4: applicare la correzione e documentare
Una volta identificata la causa, applicare la correzione in modo controllato. Per le modifiche più invasive (sostituzione hardware, rebuild dell’initramfs, cambio configurazione kernel), è fondamentale:
- Eseguire uno snapshot del sistema prima di procedere
- Procedere un passo alla volta
- Verificare dopo ogni modifica che il problema sia risolto e che nulla si sia rotto
Il passo finale, spesso trascurato, è la documentazione. Annotare cosa è andato storto, quali log hanno fornito i clue decisivi, e come è stato risolto il problema. Un ticket nel sistema di ticketing, un post nel blog interno, o anche una semplice nota in un file di testo possono fare la differenza quando lo stesso problema si ripresenterà tra sei mesi.
Strumenti essenziali da padroneggiare
Per mettere in pratica questo metodo in modo efficace, vale la pena avere familiarità con questi strumenti:
# Monitoraggio risorse
htop, btop, atop, glances
# Analisi disco e I/O
iotop, iostat, lsblk, blkid, smartctl -a /dev/sda
# Rete
ss -tlnp, netstat -tlnp, tcpdump, traceroute, mtr
# File di sistema
strace -p , lsof -i, inotifywait
# Analisi log avanzata
grep, awk, sed, logwatch, fail2ban-client status
Conclusione
Il troubleshooting su Linux non è magia: è l’applicazione di un metodo. Raccogliere i dati, analizzare i log, formulare ipotesi e testarle una alla volta, applicare la correzione e documentare. Quattro passi che, se seguiti con disciplina, permettono di affrontare con sicurezza qualsiasi problema, dai più banali ai più complessi.
La vera competenza si costruisce nel tempo, attraverso l’accumulo di esperienze documentate. Ogni errore risolto correttamente è una voce nel vostro archivio personale di soluzioni.
Fonte originale: Linux Troubleshooting: These 4 Steps Will Fix 99% of Errors – LinuxBlog.io