1 17/05/2026 12 min

Su Debian i problemi “comuni” non sono quasi mai misteriosi: di solito si concentrano su boot, rete, repository APT, servizi systemd, spazio disco, permessi e aggiornamenti kernel. Il punto non è avere cento trucchi, ma una sequenza di controlli che ti faccia capire subito in quale layer stai guardando e qual è la correzione minima reversibile. Se lavori su macchine remote, parte sempre da osservabilità: stato del servizio, log recenti, uso disco, connettività, versione dei pacchetti e ultimo change applicato.

Parti dal layer giusto: boot, rete, pacchetti o servizio

La tentazione classica è “toccare qualcosa” appena Debian sembra lenta o bloccata. È il modo più rapido per peggiorare il quadro. Il percorso più solido è questo: prima confermi se il sistema è raggiungibile, poi verifichi la rete, poi i repository, poi i servizi, poi lo storage. Se il nodo è acceso ma non risponde, il problema spesso è più basso di quanto sembri: IP errato, DNS rotto, disco pieno, journald saturo, init che non completa il boot, oppure un servizio core che fallisce in loop.

Una check-list minima, eseguita in ordine, evita molta confusione:

  1. verifica reachability e latenza con ping o ssh;
  2. controlla l’IP e la route predefinita;
  3. leggi gli ultimi errori di systemd;
  4. controlla disco e inode;
  5. verifica APT solo dopo aver escluso rete e DNS.

Debian non parte o si ferma in emergenza: journal, fs e init

Se il sistema non completa il boot, il primo artefatto da leggere è il journal del boot precedente. Su una console locale o in rescue mode, il comando più utile è spesso questo:

journalctl -xb -p err

Se trovi errori legati a filesystem, mount mancati o unità in timeout, non partire dal riavvio “sperando”. Identifica il punto esatto: una riga di fstab errata, un UUID cambiato, un disco degradato, oppure un servizio che blocca la catena di dipendenze. Un errore tipico è un mount non essenziale che impedisce il boot perché in /etc/fstab manca nofail o un timeout sensato.

Per controllare i mount e gli UUID usa:

lsblk -f
blkid
cat /etc/fstab

Se il problema è un filesystem sporco o corrotto, la correzione va fatta offline. Non forzare un fsck su una partizione montata in scrittura. In caso di dubbi, entra in rescue, smonta il volume interessato e lancia il controllo lì. Il blast radius è alto: un intervento sbagliato su storage può peggiorare il danno. Prima fai snapshot o backup se l’infrastruttura lo consente.

APT bloccato, repository rotti, chiavi scadute

Molti “problemi Debian” in realtà sono problemi di APT. Il sintomo può essere un apt update che fallisce, pacchetti non installabili, oppure warning sulle firme. La prima distinzione è semplice: errore di rete, errore DNS, errore di firma, oppure repository sbagliato per la release in uso.

Verifica subito la release:

cat /etc/debian_version
cat /etc/os-release
apt-cache policy

Se il repository non corrisponde alla release, il sintomo tipico è un 404 o un pacchetto “non disponibile”. In quel caso controlla i file in /etc/apt/sources.list e in /etc/apt/sources.list.d/. Su Debian recente è normale usare anche il formato .sources. La correzione più sicura è fare un backup del file, poi correggere solo la riga sbagliata.

Esempio di verifica rapida:

grep -R --line-number -E 'deb |URIs:|Suites:' /etc/apt/sources.list /etc/apt/sources.list.d/

Se l’errore riguarda le firme, prima controlla data e ora. Su sistemi con clock sballato, anche un repository corretto sembra “non firmato”.

timedatectl status

Se l’ora è errata, ripristina NTP invece di inseguire falsi problemi di chiavi. Solo dopo ha senso verificare il keyring o il pacchetto debian-archive-keyring. Non mettere mai chiavi in chiaro dentro script improvvisati: aggiorna i pacchetti di fiducia con il metodo distribuito dalla release, o documenta chiaramente il motivo del pinning se stai usando repository terzi.

Rete assente: IP, route, DNS e risoluzione

Quando Debian “non va in rete”, la domanda corretta non è “internet è giù?”, ma “a quale livello si rompe?”. Se l’host non pinga il gateway, il problema è locale o di L2/L3. Se pinga l’IP ma non risolve i nomi, il problema è DNS. Se risolve ma non esce, la route o il firewall sono i candidati più forti.

Questi controlli bastano a separare i casi più frequenti:

ip a
ip r
ping -c 3 1.1.1.1
getent hosts deb.debian.org
resolvectl status

Se ping 1.1.1.1 funziona ma getent hosts deb.debian.org no, il DNS è il colpevole quasi certo. Su sistemi con systemd-resolved, il punto di controllo è resolvectl status; su altri, il file /etc/resolv.conf può essere un symlink o un file statico. Non modificare a caso entrambi: capisci prima chi li gestisce.

Se usi NetworkManager, la verifica più pulita è vedere se la connessione è effettivamente attiva e con gateway corretto:

nmcli dev status
nmcli con show --active

Un caso classico su server appena clonati è l’IP statico lasciato con gateway o DNS del template. Il sintomo: SSH locale funziona, ma non esce verso l’esterno o non risolve. La correzione minima è aggiornare la configurazione di rete, poi ricaricare il profilo, senza “ripulire” la macchina. Se l’host è remoto, pianifica il rollback prima di applicare il cambio di rete.

Servizi systemd in failed: leggere il motivo, non solo il nome

Uno dei trucchi più utili su Debian è non fermarsi a systemctl status. Il servizio può essere “failed” per motivi banali: file di configurazione con sintassi errata, permessi sbagliati, porta già occupata, variabile d’ambiente mancante, dipendenza non pronta. Il nome dell’unità non basta.

Parti da questo:

systemctl status nome-servizio --no-pager
journalctl -u nome-servizio -b --no-pager

Se l’errore è di configurazione, quasi sempre il log lo dice in modo esplicito. Per esempio, Nginx e Apache segnalano il file e la riga; PostgreSQL indica spesso il parametro invalido; servizi custom mostrano l’exit code. Il trucco è distinguere tra errore permanente e crash dovuto a risorsa mancante. Un servizio che fallisce subito con Exit code 1 spesso ha un problema di configurazione. Uno che entra in timeout può dipendere da rete, storage o dipendenza esterna.

Quando il servizio è tuo, aggiungi un controllo di validazione prima del restart. Esempio per Nginx:

nginx -t

Per Apache:

apachectl configtest

Per systemd, se stai facendo un change controllato, usa sempre un backup dello snippet modificato e un restart esplicito solo dopo la validazione. In ambienti critici, meglio reload che restart quando il servizio lo supporta davvero, così eviti discontinuità inutili.

Disco pieno, inode esauriti e log che crescono senza freno

Su Debian un disco pieno non si manifesta sempre con un errore elegante. Puoi vedere login falliti, servizi che non partono, APT che si blocca, database in read-only o journald che smette di scrivere. Prima misura, poi pulisci. La metrica utile non è solo lo spazio percentuale, ma anche gli inode e i filesystem montati in scrittura.

df -hT
df -i
mount | column -t

Se df -h è ancora comodo ma df -i è al limite, hai probabilmente una valanga di file piccoli: cache, spool, mail queue, tmp o log applicativi. In quel caso il classico “libera qualche gigabyte” non basta. Devi trovare la directory che consuma inode e capire se è un comportamento normale o un loop anomalo.

Per scoprire rapidamente i top-level più pesanti:

du -xhd1 /var /home /tmp 2>/dev/null | sort -h

Se il colpevole è journald, controlla la dimensione dei log persistenti e la configurazione di retention. Non cancellare a mano file a caso dentro /var/log se il servizio è ancora vivo e li sta usando. Meglio ruotare correttamente o impostare una policy più stretta in logrotate o in journald.conf. Se serve un intervento immediato, svuotare un log specifico è meno rischioso che toccare directory intere, ma il rollback va pensato: appena il servizio riparte, il log può ricrescere se il bug non è risolto.

Kernel, moduli e aggiornamenti: quando il problema nasce dopo apt upgrade

Un altro classico è il sistema che funziona fino a un aggiornamento, poi un modulo non si carica, una periferica sparisce o il nodo non torna su con il kernel nuovo. In questi casi la prima domanda è: il problema è del kernel attuale o del kernel appena installato? La risposta la dà /var/log/apt/history.log e l’elenco dei kernel disponibili nel bootloader.

grep -E 'upgrade|install' /var/log/apt/history.log
uname -r
apt list --installed 'linux-image*' 2>/dev/null

Se il nodo è accessibile da console, il rollback più pulito è avviare il kernel precedente dal menu di GRUB e verificare se il problema scompare. Se sì, hai isolato il cambio. A quel punto puoi tenere il kernel precedente come fallback temporaneo e investigare il modulo o il driver nuovo. Non rimuovere subito il kernel che funzionava: è il tuo piano di ritorno.

Per i moduli, la verifica minima è capire se sono caricati e se il kernel li vede:

lsmod | head
modinfo nome_modulo
journalctl -k -b --no-pager | tail -200

Se un driver manca, la causa può essere un pacchetto non installato, una regressione del kernel, un firmware assente o un modulo blacklisted. L’errore da evitare è mescolare aggiornamenti e test senza cambiare una variabile per volta. Su Debian, il vantaggio è che i pacchetti sono abbastanza modulari: puoi tornare indietro con precisione, se hai tenuto traccia delle versioni.

SSH che non entra: autorizzazione, chiavi, permessi e fail2ban

Quando SSH non accetta più accessi, la causa più frequente è più semplice di quanto sembri: permessi errati su ~/.ssh, chiave sbagliata, account bloccato, oppure un filtro come fail2ban che ha bannato l’IP. Prima di cambiare la configurazione del demone, verifica il log di autenticazione e lo stato del servizio.

systemctl status ssh --no-pager
journalctl -u ssh -b --no-pager
sudo tail -n 50 /var/log/auth.log

Se usi chiavi, controlla i permessi lato client e server. Su Debian OpenSSH è severo: una home troppo aperta o una directory .ssh con permessi sbagliati basta per far fallire l’autenticazione. La verifica rapida è questa:

ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
stat -c '%a %n' ~ ~/.ssh ~/.ssh/authorized_keys

Se il blocco arriva da fail2ban, non disabilitare tutto solo per rientrare. Meglio controllare il jail e togliere il ban del solo IP di amministrazione, poi correggere la causa che ha generato il ban. Il blast radius di un cambio SSH è sempre alto: se lavori da remoto, tieni aperta una sessione secondaria o una console out-of-band prima di toccare /etc/ssh/sshd_config. Dopo ogni modifica, valida con sshd -t e ricarica il servizio, non riavviarlo a scatola chiusa.

sshd -t
systemctl reload ssh

Debian lenta: CPU, memoria, I/O e swap

“Lenta” è una diagnosi povera. Su Debian devi capire se stai vedendo saturazione CPU, pressione memoria, I/O wait o swap aggressivo. Il sintomo cambia parecchio: una macchina con CPU al 100% risponde in modo diverso da una con disco al 100% o con RAM esaurita.

Gli strumenti base sono ancora i più efficaci:

top
free -h
iostat -xz 1
vmstat 1

Se si/so in vmstat mostrano swap continuo, il problema non è “manca un po’ di RAM”, ma un set di processi che supera la memoria realmente disponibile. A quel punto puoi mitigare fermando il processo più pesante o riducendo temporaneamente il carico, ma la cura vera è nel dimensionamento o nella configurazione del servizio. Se l’I/O è il collo di bottiglia, non ha senso aumentare il numero di worker: stai solo spostando il problema.

Un trucco utile è associare la lentezza a una metrica concreta: p95 di risposta, tempo di boot, latenza SSH, oppure error rate applicativo. Senza una metrica obiettivo rischi di ottimizzare a sensazione. Su Debian server, spesso il miglioramento vero arriva da una sola correzione ben piazzata: un log troppo verboso, una query lenta, un mount remoto che blocca il boot, o un job cron che satura il disco nelle ore di punta.

Pacchetti rotti e dipendenze in stato incoerente

Capita di trovare un sistema con pacchetti half-configured, dipendenze mancanti o installazioni interrotte. La reazione corretta non è reinstallare tutto. Prima fai emergere lo stato reale del database APT/dpkg e poi chiudi l’operazione rimasta a metà.

dpkg --audit
apt -f install
apt-mark showhold

Se dpkg --audit segnala pacchetti da configurare, spesso basta completare il processo interrotto. Se ci sono hold, verifica se sono intenzionali: possono aver impedito un upgrade necessario o aver lasciato una libreria vecchia in mezzo a una release nuova. Ogni hold va documentato, perché tra qualche mese diventa difficile ricordare se era una scelta o un workaround temporaneo.

Quando una libreria critica si rompe, la correzione più sicura è riallineare i pacchetti alla release supportata, non forzare versioni casuali da repository misti. Mischiare branch diversi è una delle cause più noiose di instabilità su Debian: il sistema sembra aggiornato, ma metà stack vive su versioni incongruenti.

Un metodo pratico per non perdersi: cambia una cosa sola

Il trucco migliore su Debian non è un comando segreto, ma una disciplina. Leggi l’errore esatto, verifica il layer, fai una modifica minima, osserva l’effetto, poi decidi se estendere. Questo vale per rete, boot, APT, SSH, storage e servizi. Se cambi tre variabili insieme, poi non sai quale ha funzionato e quale ha introdotto il danno collaterale.

In pratica, una buona sequenza è questa:

  1. raccogli evidenza: log, stato, metriche, configurazione attiva;
  2. isola il layer: DNS, rete, servizio, storage, pacchetto;
  3. applica la correzione minima reversibile;
  4. verifica con lo stesso comando che mostrava il guasto;
  5. solo dopo esegui il fix strutturale o la pulizia finale.

Se vuoi davvero ridurre i tempi di troubleshooting, tieni pronti tre file mentali: journalctl per il “perché”, ip/ss/df per il “dove”, e apt/dpkg/systemctl per il “cosa”. Su Debian, molto spesso basta questo per passare da una macchina “rotta” a una diagnosi precisa in pochi minuti.