Come utili per rimuovere e pulire completamente il sistema

Pulire davvero un sistema Linux: cosa significa e cosa non significa

Quando si parla di “rimuovere e pulire completamente” un sistema Linux, il punto non è cancellare a caso file e pacchetti. Il punto è riportare la macchina a uno stato coerente: niente servizi inutili in ascolto, niente pacchetti orfani, niente configurazioni residue che si riattivano al prossimo reboot, niente log o cache che occupano spazio senza motivo, niente account o chiavi che non servono più.

La differenza tra una disinstallazione superficiale e una pulizia fatta bene è semplice: la prima libera spazio, la seconda riduce anche il rischio operativo. Un demone dimenticato può riaprire porte, un repository terzo può reinstallare dipendenze indesiderate, una vecchia unità systemd può far ripartire un servizio morto da mesi. Se il sistema è in produzione, va trattato come change controllato; se è una macchina da dismettere, la logica è simile ma con attenzione a backup, retention e cancellazione sicura dei dati.

Qui non c’è una ricetta universale valida per ogni distro, perché il comportamento di apt, dnf, zypper o pacman cambia nei dettagli. La sequenza però resta la stessa: inventario, stop, disabilitazione, rimozione, pulizia dei residui, verifica. Saltare un passaggio è il modo più rapido per lasciare sporcizia nascosta.

Inventario iniziale: sapere cosa esiste prima di toccare qualcosa

Prima di rimuovere, bisogna vedere. Non si pulisce un sistema a memoria, si parte da un inventario ripetibile. I tre punti che guardo subito sono pacchetti installati, servizi attivi e punti di montaggio o directory che consumano spazio.

Su una macchina Linux recente, questi comandi danno una fotografia utile:

systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled
apt list --installed 2>/dev/null | sed '1d'   # Debian/Ubuntu
rpm -qa | sort                                # RHEL/CentOS/Alma/Rocky
pacman -Qq                                    # Arch
findmnt -rno TARGET,SOURCE,FSTYPE,OPTIONS
sudo du -xhd1 / 2>/dev/null | sort -h

Se stai lavorando su una VPS o su un server hosting, controlla anche i path che tipicamente accumulano residui: /var/log, /var/cache, /var/tmp, /tmp, /home, /srv, /opt. Non dare per scontato che lo spazio pieno venga dal sistema: spesso il problema è una directory applicativa o una coda di log compressi che nessuno ruota più.

Servizi da fermare prima della rimozione

Se un servizio è ancora attivo mentre rimuovi il pacchetto o i file, stai creando uno stato ambiguo: il processo continua a girare con binari che magari non esistono più sul filesystem, oppure si riavvia automaticamente grazie a systemd o a un watchdog. Prima si ferma, poi si disabilita, poi si verifica che non torni su da solo.

Per i servizi noti, il flusso minimo è questo:

sudo systemctl stop nome-servizio
sudo systemctl disable nome-servizio
sudo systemctl status nome-servizio --no-pager

Se il servizio è gestito da socket activation, controlla anche le unità socket. È un dettaglio che viene ignorato spesso, e poi il demone riparte al primo accesso al socket invece che all’avvio del sistema.

systemctl list-unit-files | grep -E 'nome-servizio|\.socket'
sudo systemctl stop nome-servizio.socket
sudo systemctl disable nome-servizio.socket

Se il servizio è applicativo, guarda i log recenti prima di toccare altro. Il file varia, ma i punti tipici sono /var/log/syslog, /var/log/messages oppure il journal di systemd.

sudo journalctl -u nome-servizio -n 100 --no-pager

Rimozione dei pacchetti: dipendenze, residui e differenze tra distro

Qui si decide se vuoi togliere solo il pacchetto principale o anche la sua coda di dipendenze non più usate. La scelta dipende dal contesto: su un server multiuso conviene essere prudenti, su una macchina dedicata conviene ripulire di più. In ogni caso, la rimozione deve essere tracciabile e reversibile almeno fino al punto in cui hai confermato che non serve più.

Su Debian e derivate, il pacchetto può essere rimosso lasciando file di configurazione o eliminato in modo più netto. La distinzione conta, perché la configurazione residua può rientrare in gioco se reinstalli il software più avanti.

sudo apt remove nome-pacchetto
sudo apt purge nome-pacchetto
sudo apt autoremove --purge

Su RHEL, Alma, Rocky e derivate, la rimozione è più lineare, ma i file di configurazione personalizzati fuori dal pacchetto restano comunque dove sono. Non confondere la disinstallazione del software con la pulizia delle directory applicative.

sudo dnf remove nome-pacchetto
sudo dnf autoremove

Su Arch e derivate, la situazione cambia ancora: il sistema è più essenziale e le dipendenze orfane vanno verificate con più attenzione.

sudo pacman -R nome-pacchetto
sudo pacman -Rns nome-pacchetto

Un buon criterio operativo è questo: prima rimuovi il pacchetto principale, poi osservi quali dipendenze risultano orfane, poi decidi se eliminarle. Non fare il contrario. Se togli in blocco dipendenze condivise da altri servizi, la pulizia diventa un incidente.

File residui: dove si nascondono davvero

I residui più fastidiosi non sono i binari, ma i file sparsi: configurazioni in /etc, dati persistenti in /var/lib, cache in /var/cache, override di systemd in /etc/systemd/system, cron job in /etc/cron.*, login shell in /etc/passwd o /etc/shadow, chiavi SSH in /home/*/.ssh. Il pacchetto può essere sparito, ma l’effetto del pacchetto resta.

Per trovare quello che è rimasto, non affidarti solo a find su tutta la root se non hai motivo. Parti dai path noti del software che stai eliminando e incrocia con il database del package manager.

dpkg -L nome-pacchetto        # Debian/Ubuntu
rpm -ql nome-pacchetto        # RHEL-like
pacman -Ql nome-pacchetto     # Arch

sudo find /etc /var/lib /var/cache /opt -iname '*nome*' -o -iname '*servizio*'

Se vuoi capire cosa è “stato lasciato apposta” e cosa è davvero residuo, confronta i file con la lista del pacchetto e con la data di modifica. Un file in /etc creato dopo l’installazione non è un residuo casuale: è probabilmente una modifica operativa da valutare prima di cancellarla.

sudo stat /etc/percorso/file
sudo ls -l --time-style=long-iso /etc/percorso

Log e cache: liberare spazio senza perdere il minimo utile

La pulizia dei log va fatta con criterio. Cancellare tutto perché “occupa” è una scorciatoia che elimina anche la possibilità di ricostruire un incidente. Se il sistema è da dismettere, la priorità è diversa; se è ancora vivo, conserva almeno il necessario per audit e troubleshooting.

Per il journal di systemd puoi verificare lo spazio occupato e, se serve, ridurlo in modo controllato. La pulizia deve essere consapevole, non automatica alla cieca.

journalctl --disk-usage
sudo journalctl --vacuum-time=7d
sudo journalctl --vacuum-size=200M

Per i log tradizionali, controlla /var/log e le rotazioni. Se trovi file enormi non ruotati, spesso il problema è un servizio che scrive troppo o una configurazione di logrotate mancante o rotta.

sudo du -sh /var/log/* | sort -h
sudo ls -lh /var/log | tail

Le cache vanno trattate come materiale consumabile, ma con una distinzione netta: la cache del package manager può essere rimossa quasi sempre, quella applicativa va valutata. Per esempio, cancellare la cache di un reverse proxy o di un CMS può essere un’azione reversibile; cancellare dati temporanei di una coda o di un motore di build in corso può interrompere processi legittimi.

sudo apt clean
sudo dnf clean all
sudo rm -rf /var/cache/nomeservizio/*

Il terzo comando va usato solo se hai verificato che la directory appartiene davvero a una cache eliminabile e non a dati di lavoro. In caso di dubbio, prima fai un backup o sposta il contenuto in una posizione temporanea.

Account, chiavi e autorizzazioni: la parte che spesso rimane in giro

Quando si dismette un software o un ambiente, bisogna togliere anche gli account di servizio, le chiavi SSH, i token configurati in file e le autorizzazioni sudo specifiche. Un servizio rimosso ma con utente ancora presente non è un problema immediato, ma è un residuo di superficie d’attacco.

Controlla gli utenti locali e quelli creati per singoli servizi. Se un account esiste solo per quel demone e non ha altri ruoli, la sua eliminazione è parte della pulizia. Prima però verifica home directory, processi ancora attivi e ownership di file sparsi.

getent passwd | grep -E 'nome-servizio|app|daemon'
getent group | grep -E 'nome-servizio|app|daemon'
sudo lsof -u nomeutente

Per le chiavi SSH, controlla /home/utente/.ssh/authorized_keys, eventuali deploy key e file di configurazione in /etc/ssh/sshd_config.d/. Se togli accessi, fallo con criterio e con una sessione di emergenza aperta, altrimenti rischi di tagliarti fuori dalla macchina mentre la stai ripulendo.

Unità systemd, timer e socket: la persistenza che non si vede subito

Molti ambienti restano sporchi perché si rimuove il pacchetto ma non le unità custom. Questo succede con override in /etc/systemd/system, timer che rilanciano attività, mount unit, socket e path unit. Sono file piccoli, ma il loro effetto è grande: fanno ripartire servizi, job di manutenzione, backup o sincronizzazioni che pensavi spariti.

systemctl list-unit-files | grep -E 'nome-servizio|nome-task'
sudo find /etc/systemd/system -type f -o -type l | grep -E 'nome-servizio|nome-task'
sudo systemctl daemon-reload

Se trovi override o drop-in, documentali prima di cancellarli. Un file in /etc/systemd/system/nome-servizio.service.d/override.conf può contenere limiti, environment o path custom che servono ad altri componenti. In quel caso la rimozione va coordinata, non fatta a colpi di rm -rf.

Quando il sistema va pulito fino in fondo: macchina da dismettere

Se l’obiettivo non è “ripulire il server” ma “chiuderlo definitivamente”, il lavoro cambia scala. Qui la verifica non è più solo funzionale, ma anche di retention e sicurezza. Il punto non è lasciare il sistema immacolato, ma assicurarsi che non contenga dati recuperabili oltre il necessario.

Il flusso corretto, in sintesi, è: esportare ciò che va conservato, verificare backup, revocare accessi, fermare servizi, rimuovere dati applicativi, fare pulizia di log e cache, quindi procedere alla cancellazione o decommissioning del volume. Se il disco deve essere riutilizzato, la cancellazione sicura dipende dal tipo di storage: su SSD e storage virtualizzato la procedura va scelta con attenzione, perché i vecchi metodi basati su scrittura sequenziale non sono sempre appropriati.

Non improvvisare la cancellazione sicura: il metodo cambia tra disco fisico, volume cifrato, snapshot cloud e storage condiviso. Se non hai certezza del supporto, chiudi il gap consultando la documentazione del provider o del controller e verifica prima il tipo di device con lsblk -f e blkid.

lsblk -f
blkid
sudo wipefs -n /dev/sdX

Il terzo comando è solo di verifica non distruttiva: mostra i metadati presenti sul device senza cancellarli. Se il target è corretto e il contesto lo permette, la cancellazione va pianificata con il relativo rollback, che in questo caso è il ripristino da backup o reimaging del nodo.

Verifica finale: come capire se la pulizia è coerente

La verifica finale deve rispondere a tre domande: il servizio è sparito davvero, il sistema non ha più riferimenti residui, lo spazio liberato è quello atteso. Se una delle tre risposte è no, la pulizia è incompleta.

Controlli minimi utili:

1. Il servizio non è più attivo: systemctl status nome-servizio deve mostrare inactive, disabled o unit non trovata, a seconda del caso.
2. La porta non è più in ascolto: ss -lntup non deve mostrare il processo rimosso.
3. Il pacchetto non è più installato: dpkg -l, rpm -qa o pacman -Q non devono restituirlo.
4. Le directory residue sono state valutate e, se non servivano, eliminate con criterio.
5. Lo spazio disco è coerente con quanto atteso: df -h e du -xhd1 devono mostrare il rientro dello spazio.

Un controllo che considero sempre utile è una ricerca mirata di riferimenti al nome del software, senza esagerare con la scansione globale del filesystem. Serve a trovare gli ultimi frammenti di configurazione o log che altrimenti restano invisibili.

sudo grep -RIn --exclude-dir={proc,sys,dev,run} 'nome-servizio' /etc /var 2>/dev/null

Se il comando restituisce ancora riferimenti in file di configurazione o unità systemd, non sei alla fine: sei a metà. La pulizia completa non è una rimozione di pacchetti, è una bonifica dell’insieme.

Una procedura pratica che regge in quasi tutti i casi

Se devi operare su un sistema Linux e vuoi evitare errori banali, questa sequenza è quella più robusta:

1. Identifica il software, il servizio e i path coinvolti.
2. Salva uno snapshot logico: elenco pacchetti, unità attive, spazio disco, file di configurazione rilevanti.
3. Ferma e disabilita il servizio, incluse socket e timer collegati.
4. Rimuovi il pacchetto con il metodo della distro.
5. Elimina o archivia configurazioni, dati e cache solo dopo verifica.
6. Controlla log, account e permessi residui.
7. Valida il risultato con status servizio, porte in ascolto e spazio liberato.

Il vantaggio di questa sequenza è che separa il rischio tecnico dal risultato atteso. Prima osservi, poi cambi, poi verifichi. È il contrario della pulizia “creativa”, che lascia il sistema apparentemente ordinato ma con pezzi vivi sotto la superficie.

Se hai dubbi su un file o su una directory, la scelta corretta non è cancellare a intuito: è spostare, versionare o annotare il path e il motivo per cui esiste. In ambienti condivisi o hostati, questo dettaglio fa la differenza tra manutenzione e interruzione di servizio.