Linux: 4 passi per risolvere il 99% degli errori

Nel mondo Linux, affrontare un errore può essere scoraggiante, soprattutto per chi si approccia per la prima volta al sistema. Tuttavia, la buona notizia è che quasi tutti i problemi possono essere risolti seguendo un approccio metodico e strutturato. Ogni errore, anche il più oscuro, contiene indizi su cosa non funziona. Imparare a raccogliere informazioni, interpretare log, testare ipotesi e documentare le soluzioni consente di ridurre il tempo di risoluzione da ore a pochi minuti.

All’approccio vincente si fa comunemente riferimento con l’acronimo inglese GLAD, ovvero Gather, Look, Analyze, Document. In italiano si può tradurre letteralmente come Raccogli, Controlla, Analizza, Documenta: è proprio quello di cui parliamo nel seguito.

1) Raccogliere indizi e definire il problema

Il primo passo consiste nel capire esattamente che cosa non funziona. Considerazioni vaghe sul problema non aiutano. Occorre essere precisi:

• Quale servizio o applicazione ha generato l’errore?
• Quali operazioni precedenti potrebbero averlo causato (aggiornamenti, modifiche a configurazioni, riavvii)?
• Quando si è verificato per la prima volta?

Se un’applicazione non si avvia su Linux, il primo suggerimento è provare ad avviarla dalla finestra del terminale. Digitandone il nome e premendo Invio, si vedranno messaggi di errore come “libXYZ.so non trovato” o “cannot open display”.

Per i servizi di sistema, il comando systemctl status seguito dal nome del servizio mostra se è attivo, inattivo o in errore.

Capire le operazioni precedenti che potrebbero aver causato l’errore

Ci sono alcuni semplici comandi Linux che aiutano ad accertare quali modifiche potrebbero verosimilmente aver provocato un errore. Il comando seguente, ad esempio, è utile per controllare gli aggiornamenti recenti:

cat /var/log/dpkg.log | grep "upgrade"

È inoltre possibile controllare le modifiche applicate sulle configurazioni:

ls -lt /etc/<nome-servizio>/

L’istruzione ordina i file per data di modifica in modo tale da far emergere eventuali cambi recenti.

Ancora, con last reboot, si possono verificare i riavvii recenti.

Quando si è verificato il problema?

Il comando che segue permette di analizzare i log di sistema, mostrando gli ultimi eventi registrati, compresi eventuali errori:

journalctl -xe

Con una sintassi leggermente diversa, è possibile estrarre i log specifici relativi a un servizio. Nell’esempio di seguito prendiamo quelli relativi a Nginx:

journalctl -u nginx
tail -n 50 /var/log/nginx/error.log

Tentare di riprodurre il problema

In molti casi, una delle strategie migliori per togliere le castagne dal fuoco è provare a riprodurre il problema riscontrato o segnalato in precedenza.

Nel caso di applicazioni Linux dotate di interfaccia grafica (GUI), si può digitare:

<nome_applicazione> --verbose

Per script o servizi:

systemctl restart <servizio>

A questo punto si può controllare il log per capire se l’errore è annotato e circostanziato.

2) Controllare lo stato del sistema

Una volta definito il problema, il passo successivo consiste nel verificare lo stato del sistema, avvalendosi ancora una volta dei log più pertinenti.

• CPU e RAM: top, htop
• Spazio su disco: df -h, du
• Networking: ip a, ping

Per il controllo dei log (in parte ne abbiamo già parlato nei paragrafi precedenti), si possono usare le istruzioni di seguito:

• Boot e kernel: dmesg, journalctl -xb
• Servizi: journalctl -u <servizio>, directory /var/log/
• Eventi di rete: traceroute, ping, controllo delle interfacce mediante /etc/network/interfaces
• Unità di memorizzazione: lsblk, blkid, informazioni SMART (smartctl -a /dev/sdX)

Nel caso in cui si avesse a che fare con log di grandi dimensioni, si possono utilizzare strumenti di ricerca rapida:

grep -i error /var/log/syslog
journalctl | grep "segfault"

Ovviamente si tratta di un esempio pratico: segfault fa riferimento a uno degli errori più comuni e riconoscibili su Linux. Indica una “Segmentation Fault”, ossia un crash di un programma dovuto a un accesso errato alla memoria. Altri esempi potrebbero essere questi:

journalctl | grep "permission denied"
journalctl -u nginx | grep "failed"
journalctl -b -1 | grep "disk"

3) Analizzare e provare possibili soluzioni

Con errori e log alla mano, si passa all’analisi. È importante formulare ipotesi basate sulle informazioni raccolte e testarle una alla volta.

Esempi di ipotesi comuni:

• Segmentation fault. Possibile corruzione della memoria o libreria danneggiata.
• Permission denied. Verifica permessi file o regole SELinux/AppArmor.
• Device not found. UUID del disco cambiato o partizione mancante.

Per testare le soluzioni, è opportuno modifica una variabile o ripristinare un pacchetto alla volta. Controllando allo stesso tempo configurazioni, librerie o dipendenze mancanti.

Testare una soluzione alla volta

Per ripristinare un pacchetto o libreria mancante, si può utilizzare il package manager della distribuzione Linux in uso. Esempio:

sudo apt reinstall nome-pacchetto  # Debian/Ubuntu
sudo yum reinstall nome-pacchetto  # CentOS/RHEL

Può essere necessario verificare e aggiornare delle configurazioni specifiche:

sudo nano /etc/nome_servizio/config.conf

Si può eventualmente valutare la creazione di un nuovo file di configurazione di test per poi riavviare il servizio che lamentava problemi: systemctl restart <servizio>.

Se il problema riguarda un container Docker, la procedura di risoluzione del problema passa per la verifica delle porte utilizzate, delle variabili d’ambiente e dei volumi:

docker logs <nome-container>
docker compose up -d
docker run -it <nome-immagine> /bin/bash

4) Applicare la soluzione e documentare l’intervento effettuato

Dopo aver identificato la causa, è opportuno provare ad applicare la soluzione muovendosi con cautela. È bene creare backup o snapshot prima di interventi critici, effettuare un test approfondito dopo la correzione quindi documentare nel dettaglio gli interventi apportati per futuri riferimenti o condivisione con collaboratori e colleghi.

La documentazione può essere semplice (note personali), pubblica (forum, blog) o interna, ma è fondamentale per ridurre i tempi di intervento qualora fosse necessario gestire le medesime problematiche.

Suggerimenti pratici aggiuntivi

In generale è ragionevole effettuare i test in un ambiente sicuro, avvalendosi di macchine virtuali e snapshot prima di applicare modifiche critiche.

Per accedere ai comandi diagnostici che si utilizzano di frequente, si può attingere alla cronologia, ad esempio utilizzando history quindi scrivendo !n. Al posto di n va indicato il numero del comando, visualizzato nella cronologia, che s’intende ripetere. Ne parliamo nell’articolo sulla Cronologia comandi.

Si possono inoltre creare alias: l’istruzione seguente aggiunge un alias logs che permette di richiamare rapidamente il comando indicato:

alias logs="journalctl -xe | tail -n 50"

Conclusioni

Gestire gli errori su Linux può inizialmente sembrare complesso, ma seguendo un approccio metodico come quello descritto (GLAD) è possibile risolvere quasi tutti i problemi in modo rapido e sicuro. Il trucco è procedere passo dopo passo: raccogliere informazioni precise, analizzare i log e lo stato del sistema, formulare ipotesi plausibili e testare una soluzione alla volta.

Documentare ogni intervento, sia per uso personale sia per condivisione con colleghi o comunità Linux, è altrettanto importante: crea un archivio di conoscenze pratiche che può tornare utile mesi o anni dopo, specialmente quando si affrontano errori ricorrenti.

In ogni caso, è fondamentale muoversi con la massima cautela: utilizzare backup, snapshot o ambienti di test può prevenire complicazioni durante le operazioni più critiche. Con pazienza, metodo e attenzione, la risoluzione dei problemi su Linux diventa non solo più efficace, ma anche un’occasione per imparare e padroneggiare meglio il sistema.