Log Linux e troubleshooting: come capire cosa non funziona

Quando qualcosa non funziona su Linux, il primo istinto è spesso cercare subito una soluzione online.

Un servizio non parte, la rete sembra bloccata, un programma restituisce un errore di permessi, il disco è pieno oppure il sistema diventa improvvisamente lento. In questi casi è facile finire su forum, blog o video e iniziare a provare comandi uno dopo l’altro.

A volte il problema si risolve.

Ma questo non significa necessariamente aver capito cosa sia successo.

Il troubleshooting Linux funziona molto meglio quando smettiamo di cercare una soluzione casuale e iniziamo invece a costruire una diagnosi. Linux, infatti, mette a disposizione moltissime informazioni utili per capire cosa non funziona: log, journal di systemd, messaggi del kernel, stato dei servizi, utilizzo del disco e memoria disponibile.

L’obiettivo non è imparare a memoria decine di comandi. È imparare a leggere il sistema.

Cos’è il troubleshooting su Linux

Il troubleshooting è il processo con cui si cerca di individuare la causa di un problema.

Sembra una definizione banale, ma contiene una differenza importante.

Il problema che vediamo non è necessariamente la causa reale.

Un sito che non si apre potrebbe dipendere dal browser, ma anche dal DNS, dal gateway, dal firewall, dalla scheda di rete o direttamente dal server remoto.

Un servizio fallito potrebbe avere una configurazione errata, ma potrebbe anche non riuscire a leggere un file, non avere spazio sul disco oppure dipendere da un altro servizio non disponibile.

Questo significa che il troubleshooting non consiste semplicemente nel reagire all’errore visibile. Consiste nel restringere progressivamente il problema fino a individuare il livello corretto.

In Linux questo approccio funziona particolarmente bene perché il sistema è costruito a livelli: filesystem, permessi, processi, servizi, rete, memoria, driver e kernel. Quando abbiamo una buona mappa mentale di questi componenti, anche gli errori diventano più leggibili.

Cos’è un log in Linux

Un log è una registrazione degli eventi che avvengono nel sistema o all’interno di un’applicazione.

Possiamo immaginarlo come un diario tecnico.

Quando un servizio viene avviato, può essere registrato un messaggio.

Quando un’applicazione incontra un errore, può scriverlo nel proprio log.

Quando il kernel rileva un dispositivo o incontra un problema hardware, può produrre un messaggio.

Quando un utente prova ad autenticarsi o un processo termina in modo anomalo, anche questi eventi possono lasciare una traccia.

È importante però capire che un log non contiene soltanto errori.

Può contenere normali messaggi informativi, warning, informazioni di stato e dettagli che precedono l’errore vero e proprio.

Ed è proprio questo contesto a rendere i log così utili.

Se leggiamo soltanto una riga come “servizio terminato”, sappiamo poco. Se però alcune righe prima troviamo “permission denied” oppure “cannot open configuration file”, la situazione cambia completamente.

Il log inizia a raccontarci la sequenza degli eventi.

Perché il tempo è importante nel troubleshooting

Uno degli elementi più sottovalutati durante la diagnosi è il tempo.

Quando è iniziato il problema?

Dopo un aggiornamento?

Dopo un riavvio?

Dopo aver modificato un file di configurazione?

Dopo aver installato un nuovo pacchetto?

Dopo aver collegato un dispositivo?

Queste domande possono ridurre enormemente il campo di ricerca.

Se un servizio funzionava fino a pochi minuti prima e subito dopo una modifica alla configurazione smette di partire, quella modifica diventa un ottimo candidato.

Lo stesso vale per la rete. Se il problema compare immediatamente dopo l’attivazione di una VPN o una modifica al firewall, abbiamo già una direzione molto più precisa.

Troubleshooting significa anche ricostruire una sequenza temporale.

Dove si trovano i log Linux: /var/log

Nel filesystem Linux, una delle directory storicamente più importanti per i log è /var/log.

La directory /var contiene dati variabili, cioè informazioni che cambiano mentre il sistema viene utilizzato. I log rientrano perfettamente in questa categoria.

Dentro /var/log possiamo trovare file relativi al sistema, all’autenticazione, ai servizi, alle applicazioni, ai package manager, ai server web e a molti altri componenti.

Il contenuto può cambiare in base alla distribuzione e alla configurazione.

Per questo non è particolarmente utile memorizzare una lista rigida di file.

Il concetto importante è sapere che /var/log rappresenta uno dei principali luoghi da controllare quando vogliamo capire cosa è successo nel sistema.

Il journal di systemd

Nelle distribuzioni moderne basate su systemd, oltre ai log tradizionali esiste anche il journal.

Systemd non gestisce soltanto l’avvio dei servizi. Uno dei suoi componenti, systemd-journald, raccoglie molti messaggi provenienti dal sistema.

Il journal può contenere informazioni relative ai servizi, al kernel, al boot e ad altri componenti dello user space.

Questo lo rende una fonte particolarmente utile durante il troubleshooting.

Lo strumento principale per consultare queste informazioni è journalctl.

Come usare journalctl nel troubleshooting

journalctl può mostrare una grande quantità di dati.

Il punto però non è leggere tutto.

La sua utilità aumenta quando iniziamo a filtrare.

Se stiamo analizzando un determinato servizio, ci interessano i messaggi di quel servizio.

Se il problema si è verificato durante l’ultimo avvio, ci interessa quel boot.

Se il problema è comparso pochi minuti fa, possiamo concentrare l’analisi su quell’intervallo temporale.

Questo è un principio fondamentale del troubleshooting: ridurre il rumore.

Più restringiamo il contesto, più diventa facile individuare l’informazione utile.

Kernel, hardware e dmesg

Non tutti i problemi nascono nello user space.

Quando sospettiamo un problema legato a hardware, driver o dispositivi, dobbiamo guardare più in basso.

Qui entra in gioco dmesg.

Questo comando permette di osservare i messaggi del buffer del kernel.

Può essere utile quando un dispositivo USB non viene riconosciuto, una scheda di rete ha problemi, un filesystem genera errori oppure un disco mostra comportamenti anomali.

In questi casi, il kernel spesso dispone di informazioni che non troviamo direttamente nell’applicazione che manifesta il problema.

Ancora una volta, il punto è capire il livello coinvolto.

Errori di permessi

Uno degli errori più comuni su Linux è Permission denied.

Quando compare, la tentazione può essere quella di aggiungere immediatamente sudo.

Ma non è sempre la soluzione corretta.

Un errore di permessi significa prima di tutto che dobbiamo capire chi sta eseguendo l’operazione, chi possiede la risorsa e quali permessi sono configurati.

Linux distingue proprietario, gruppo e altri utenti, e applica permessi di lettura, scrittura ed esecuzione.

Il problema potrebbe essere realmente un’operazione amministrativa.

Ma potrebbe anche essere un file con proprietario sbagliato, una directory configurata male oppure un’applicazione che sta lavorando nel percorso sbagliato.

Usare sudo senza capire la causa può soltanto nascondere il problema.

Problemi di rete

La rete è un ottimo esempio di troubleshooting a livelli.

Dire “internet non funziona” è troppo generico.

Prima dobbiamo capire se la scheda è stata rilevata.

Poi se l’interfaccia di rete è attiva.

Poi se ha un indirizzo IP.

Poi se esiste un gateway corretto.

Poi se riusciamo a raggiungere un indirizzo remoto.

Solo dopo ha senso verificare DNS, firewall e servizio applicativo.

Questo approccio evita di modificare componenti che non hanno nulla a che fare con il problema.

Se non abbiamo un indirizzo IP, non ha senso iniziare dal DNS.

Se raggiungiamo un IP ma non un nome host, invece, il DNS diventa immediatamente sospetto.

Il punto in cui vediamo l’errore non è sempre la causa

Questo è probabilmente uno dei concetti più importanti dell’intero troubleshooting Linux.

Supponiamo che il browser non riesca ad aprire un sito.

Il browser è il punto in cui vediamo il problema.

Ma la causa potrebbe essere altrove.

Potrebbe dipendere dalla rete locale, dal gateway, dal DNS, dal firewall oppure dal server remoto.

Lo stesso principio vale per quasi ogni componente.

Un database che non parte potrebbe avere un problema di configurazione, ma potrebbe anche trovare il disco pieno.

Un servizio potrebbe fallire perché non ha memoria sufficiente.

Un’applicazione potrebbe non avviarsi perché non riesce a leggere un file.

Il sintomo è soltanto il punto di osservazione.

La diagnosi serve a trovare il punto di origine.

Servizi falliti e systemctl status

Quando un servizio gestito da systemd non parte, uno dei primi comandi da utilizzare è systemctl status.

Questo ci permette di vedere se il servizio è attivo, inattivo o fallito.

Spesso vengono mostrati anche il processo associato e gli ultimi messaggi disponibili.

Non sempre è sufficiente per trovare la causa completa, ma è un ottimo punto di partenza.

Da lì possiamo passare al journal e cercare informazioni più dettagliate.

La sequenza tipica diventa quindi molto semplice: osservare lo stato, leggere i messaggi, approfondire il journal e soltanto dopo intervenire.

Disco pieno e comando df

Un filesystem pieno può produrre errori molto diversi.

Un’applicazione non riesce a salvare.

Un database non può scrivere nuovi dati.

Un servizio fallisce.

Un aggiornamento non si completa.

Un processo non riesce a creare un file temporaneo.

Per questo, quando iniziano a comparire più errori di scrittura contemporaneamente, controllare lo spazio disponibile è una verifica molto semplice ma estremamente utile.

Il comando df permette di vedere lo spazio totale, utilizzato e disponibile sui filesystem montati.

Questo è importante perché non è detto che sia “pieno il disco” in generale.

Potrebbe essere pieno soltanto il filesystem root oppure una partizione specifica, ad esempio quella che contiene /var.

Una volta identificato il filesystem pieno, dobbiamo però continuare la diagnosi.

Il problema potrebbe essere causato da log cresciuti troppo, backup, cache, file temporanei o database.

Il troubleshooting non finisce quando scopriamo che manca spazio. Dobbiamo anche capire perché.

Memoria insufficiente e comando free

La memoria è un altro elemento che genera spesso interpretazioni sbagliate.

Linux utilizza la RAM anche per cache e buffer, quindi vedere una quantità elevata di memoria usata non significa automaticamente che il sistema sia in difficoltà.

Il comando free permette di osservare RAM e swap.

Il valore importante non è soltanto la memoria completamente libera, ma soprattutto quella disponibile.

Quando la pressione sulla memoria aumenta, possiamo osservare rallentamenti, maggiore utilizzo dello swap e processi che consumano grandi quantità di RAM.

In situazioni estreme, il kernel può intervenire per liberare memoria e terminare alcuni processi.

Anche qui vale la stessa regola: misurare prima di concludere.

Un computer lento non significa automaticamente che serva più RAM.

I problemi possono essere collegati

Uno degli aspetti interessanti di Linux è che i diversi sottosistemi collaborano continuamente.

Per questo anche gli errori possono essere collegati.

Un servizio che non parte potrebbe avere un problema di configurazione, ma potrebbe anche dipendere da:

• permessi errati;
• rete non disponibile;
• disco pieno;
• memoria insufficiente;
• dipendenze non avviate.

Questo è uno dei pochi casi in cui un elenco aiuta davvero a vedere la relazione tra i livelli.

Il punto importante è che non dobbiamo fermarci all’etichetta dell’errore.

Dire “è un problema di servizio” non basta.

Dobbiamo capire perché quel servizio sta fallendo.

Un metodo semplice per il troubleshooting Linux

Possiamo riassumere tutto il processo in quattro parole:

osservare, leggere, isolare, correggere.

Prima osserviamo il problema in modo preciso.

Non “Linux non funziona”, ma “questo servizio non parte” oppure “non riesco a scrivere in questa directory”.

Poi leggiamo gli errori disponibili.

Terminale, log, journal, stato del servizio e messaggi del kernel sono le nostre fonti principali.

Successivamente isoliamo il livello coinvolto.

È un problema di permessi? Di rete? Di memoria? Di disco? Di servizio? Di hardware?

Solo dopo arriviamo alla correzione.

E qui è importante cambiare una cosa alla volta.

Se modifichiamo cinque configurazioni insieme e il problema scompare, non sapremo cosa abbia realmente risolto il problema.

Come cercare meglio una soluzione online

Internet rimane naturalmente una risorsa preziosa.

La differenza sta nel modo in cui cerchiamo.

Una ricerca come “Linux non funziona” produce risultati estremamente generici.

Una ricerca basata sul componente, sulla distribuzione e sul messaggio di errore preciso è molto più efficace.

Più è accurata la diagnosi preliminare, migliore sarà anche la qualità della ricerca.

Il troubleshooting non elimina quindi la necessità di cercare informazioni.

Ci permette semplicemente di fare domande migliori.

I comandi Linux più utili per iniziare

Per questo tipo di troubleshooting non serve conoscere decine di strumenti.

Cinque comandi coprono già molte situazioni comuni.

journalctl serve per leggere il journal e gli eventi.

dmesg permette di osservare i messaggi del kernel.

systemctl status è un ottimo punto di partenza per i servizi.

df permette di controllare lo spazio dei filesystem.

free permette di osservare memoria RAM e swap.

La cosa importante, però, non è memorizzare i comandi.

È capire quale domanda stiamo facendo al sistema.

Esempio: servizio web non raggiungibile

Immaginiamo un server web che improvvisamente non risponde più.

Una reazione impulsiva potrebbe essere reinstallare il software.

Ma una diagnosi ordinata parte da domande molto più semplici.

Il servizio è attivo?

Se non lo è, cosa dice systemctl status?

Cosa troviamo nel journal?

Il servizio sta ascoltando sulla porta corretta?

La macchina è raggiungibile in rete?

Il firewall permette quella connessione?

Ogni risposta elimina alcune possibilità.

In questo modo il problema diventa progressivamente più piccolo.

Quando il troubleshooting è davvero concluso

Un problema non è completamente diagnosticato quando diciamo soltanto:

“Adesso funziona.”

Una diagnosi è molto più solida quando possiamo dire:

“Non funzionava perché…”

Il servizio non partiva perché il file di configurazione aveva un errore.

L’applicazione non riusciva a scrivere perché il filesystem era pieno.

La rete non funzionava perché mancava la rotta corretta.

Il comando falliva perché l’utente non aveva i permessi necessari.

Quando possiamo spiegare la causa e la correzione, abbiamo realmente capito il problema.

Conclusione

Il troubleshooting Linux non è una gara a chi conosce più comandi.

È un metodo.

I log ci mostrano cosa è successo.

/var/log e il journal ci permettono di ricostruire gli eventi.

dmesg ci porta più vicino al kernel e all’hardware.

systemctl status ci aiuta a capire lo stato dei servizi.

df e free ci permettono di verificare due risorse fondamentali come disco e memoria.

Ma il concetto più importante resta questo:

osservare, leggere, isolare, correggere.

Quando iniziamo a ragionare in questo modo, Linux smette di sembrare un sistema pieno di errori misteriosi e diventa qualcosa di molto più leggibile.

Non serve sapere tutto.

Serve sapere dove guardare.