logrotate: Configurare Rotazione Log su Linux

La gestione dei log è un pilastro fondamentale per qualsiasi amministratore di sistema Linux. Senza una strategia efficace, i file di log possono crescere a dismisura, saturando lo spazio disco, compromettendo le performance del sistema e rendendo difficile l’analisi di eventi critici o la risoluzione di problemi. In un ambiente enterprise, dove centinaia di server generano terabyte di dati ogni giorno, un disco pieno a causa di log non gestiti può fermare interi servizi, con costi operativi significativi.

logrotate è lo strumento standard su Linux per automatizzare la rotazione, la compressione e la rimozione dei file di log. Permette di definire regole precise per ogni applicazione, garantendo che i log siano sempre disponibili per l’analisi ma senza occupare spazio inutilmente. Una configurazione errata di logrotate è una delle cause più comuni di dischi pieni che ho incontrato in ambienti con 2.000 workstation e 300+ VM VMware, e una corretta implementazione può prevenire interruzioni di servizio e semplificare enormemente il lavoro di debugging e monitoraggio.

Testato su: Ubuntu 24.04 LTS · logrotate 3.21.0 · Ottobre 2026

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di un sistema Linux (preferibilmente Ubuntu o Debian, ma i concetti si applicano a qualsiasi distribuzione) con privilegi di sudo. logrotate è preinstallato sulla maggior parte dei sistemi Linux moderni. Useremo un’applicazione fittizia chiamata app che scrive i suoi log in /var/log/app/ e ha un servizio systemd chiamato app che deve essere ricaricato dopo la rotazione dei log.

Come funziona logrotate e quando parte

logrotate è un’utility che gira in background, solitamente richiamata da cron. Su molte distribuzioni, esiste un file /etc/cron.daily/logrotate che esegue il comando logrotate /etc/logrotate.conf una volta al giorno. Il file /etc/logrotate.conf contiene le configurazioni globali e include tutti i file presenti nella directory /etc/logrotate.d/. È in quest’ultima directory che andremo a creare i file di configurazione specifici per le nostre applicazioni.

Quando logrotate viene eseguito, legge le configurazioni e verifica se è il momento di ruotare i log in base alle regole definite (es. giornalmente, settimanalmente, per dimensione). Se una rotazione è necessaria, procede con le azioni specificate: rinomina il file di log corrente, ne crea uno nuovo (o lo svuota), lo comprime e rimuove le copie più vecchie.

Il file di configurazione di un’applicazione

Ogni applicazione o servizio che genera log può avere un proprio file di configurazione dedicato in /etc/logrotate.d/. Questo approccio modulare semplifica la gestione e la manutenzione. Creiamo un esempio per la nostra app fittizia:

# /etc/logrotate.d/app
/var/log/app/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 app app
    postrotate
        systemctl reload app
    endscript
}

Analizziamo le direttive principali:

• /var/log/app/.log: Specifica i file di log su cui applicare le regole. L’asterisco () indica tutti i file con estensione .log all’interno della directory /var/log/app/.
• daily: La rotazione avverrà ogni giorno. Altre opzioni comuni sono weekly, monthly, yearly.
• rotate 14: Verranno mantenute 14 copie dei log ruotati. Dopo la quattordicesima rotazione, la copia più vecchia verrà eliminata.
• compress: Comprime i log ruotati (solitamente con gzip).
• delaycompress: Ritarda la compressione di un log ruotato al ciclo successivo. Utile se il servizio potrebbe ancora scrivere sul file appena ruotato per un breve periodo.
• missingok: Non genera un errore se il file di log non esiste.
• notifempty: Non ruota il log se è vuoto.
• create 0640 app app: Crea un nuovo file di log con permessi 0640 e proprietario/gruppo app:app dopo la rotazione. Questa è l’opzione preferita quando il servizio è in grado di riaprire il nuovo file di log.

Frequenza, numero di copie e compressione

La scelta della frequenza di rotazione (daily, weekly, monthly, yearly) dipende dal volume di log generato e dalla necessità di analisi. Per servizi ad alto traffico, daily è spesso la scelta migliore. Il parametro rotate N definisce per quanti cicli i log ruotati verranno conservati. Ad esempio, rotate 7 con daily significa che si avranno 7 giorni di log storici compressi.

La direttiva compress è quasi sempre consigliabile per risparmiare spazio disco. delaycompress è particolarmente utile in ambienti dove i servizi potrebbero mantenere un handle aperto sul file di log per un breve periodo dopo la rotazione. In questo modo, il file viene rinominato al primo ciclo e compresso solo al secondo, evitando problemi di accesso concorrente.

copytruncate o create: la differenza che conta

Questo è uno dei punti più critici nella configurazione di logrotate e spesso fonte di errori. La scelta tra copytruncate e create dipende da come l’applicazione gestisce i suoi file di log.

• create (predefinito se non specificato e non si usa copytruncate): logrotate sposta il file di log corrente (es. da app.log a app.log.1) e crea un nuovo file app.log vuoto. Questa è l’opzione più efficiente. Tuttavia, richiede che l’applicazione sia in grado di riaprire il nuovo file di log. Se l’applicazione continua a scrivere sul file rinominato, i nuovi eventi andranno persi o scritti in un file ‘vecchio’ che non verrà più monitorato correttamente. Per ovviare a questo, si usa la direttiva postrotate.
• copytruncate: logrotate crea una copia del file di log corrente e poi svuota il file originale. Il servizio continua a scrivere nel file originale, che è stato svuotato. Questo metodo è meno efficiente (richiede più I/O) ma è più sicuro per applicazioni che non possono essere facilmente riavviate o che non supportano la riapertura dei log. Non richiede un postrotate per far riaprire il log al servizio, ma può causare la perdita di alcuni eventi di log tra la copia e lo svuotamento del file.

Leggi anche: Comando find Linux: 20 Esempi Pratici

postrotate: far riaprire i log al servizio

Come accennato, se si usa la direttiva create (o se non si usa copytruncate), è fondamentale far sapere al servizio che il suo file di log è stato spostato e che deve iniziare a scrivere su un nuovo file. Questo si fa con la direttiva postrotate.

    postrotate
        systemctl reload app
    endscript

Il blocco postrotate/endscript contiene i comandi che verranno eseguiti dopo che la rotazione è avvenuta. In questo caso, systemctl reload app invia un segnale di ricarica al servizio app. Molti servizi (come nginx, apache, rsyslog) sono progettati per riaprire i loro file di log quando ricevono un segnale SIGHUP (che systemctl reload spesso invia). È fondamentale verificare la documentazione del servizio per capire quale comando sia il più appropriato per fargli riaprire i log senza interrompere il servizio. Leggi anche: Creare Servizio systemd: Riavvio Automatico e Dipendenze

Ruotare per dimensione invece che per data

Oltre alla rotazione basata sul tempo, logrotate supporta anche la rotazione basata sulla dimensione del file. Questo è particolarmente utile per servizi che generano un volume di log molto variabile o estremamente elevato, dove una rotazione giornaliera potrebbe essere insufficiente o eccessiva.

/var/log/another_app/*.log {
    size 100M
    rotate 5
    compress
    postrotate
        systemctl reload another_app
    endscript
}

La direttiva size 100M indica che il log verrà ruotato quando raggiunge i 100 Megabyte. Puoi usare K per Kilobyte, M per Megabyte e G per Gigabyte. Se si specificano sia size che una frequenza temporale (daily, ecc.), logrotate ruoterà il log ogni volta che una delle due condizioni è soddisfatta.

Provare la configurazione senza toccare i file

Prima di implementare una nuova configurazione in produzione, è essenziale testarla. logrotate offre modalità di debug che simulano l’esecuzione senza apportare modifiche ai file reali.

Per un’esecuzione in modalità debug:

sudo logrotate -d /etc/logrotate.d/app

Questo comando mostrerà cosa farebbe logrotate, inclusi i motivi per cui un log verrebbe o meno ruotato, e quali comandi postrotate verrebbero eseguiti. È uno strumento prezioso per il troubleshooting.

Per forzare una rotazione (utile per testare il postrotate o per liberare spazio in emergenza):

sudo logrotate -f /etc/logrotate.d/app

Questo ignorerà le condizioni di frequenza e dimensione e forzerà la rotazione dei log specificati. Usalo con cautela in produzione, poiché potrebbe innescare il postrotate e ricaricare il servizio in un momento inopportuno.

Infine, per controllare lo stato delle rotazioni di logrotate (quando è stato ruotato l’ultima volta un determinato log):

cat /var/lib/logrotate/status

Questo file contiene informazioni sull’ultima volta che ogni log è stato ruotato, essenziale per verificare che logrotate stia funzionando come previsto.

Errori comuni e troubleshooting

1. Log che non vengono ruotati: Controlla che il file di configurazione sia in /etc/logrotate.d/ e che sia richiamato da /etc/logrotate.conf. Verifica che il cronjob di logrotate sia attivo (/etc/cron.daily/logrotate). Controlla i permessi dei file di log e delle directory. Un errore comune è che logrotate non abbia i permessi per scrivere nella directory dei log o per rinominare i file. Leggi anche: Active Directory: Errore ‘Relazione di Trust’ e Soluzioni
2. Servizio che non riapre il log: Se usi create e il servizio non riapre il log, i nuovi eventi andranno persi. Assicurati che il comando nel blocco postrotate sia corretto e che il servizio sia configurato per rispondere al segnale appropriato (es. SIGHUP). Testalo con sudo logrotate -f.
3. Log files corrotti con copytruncate: Se un servizio scrive costantemente e in modo intenso, copytruncate può portare a log corrotti o incompleti, poiché c’è un piccolo intervallo tra la copia e lo svuotamento in cui il servizio potrebbe scrivere. In questi casi, create con un postrotate robusto è preferibile.
4. Permessi errati sui nuovi log: Se il nuovo file di log viene creato con permessi sbagliati, il servizio potrebbe non essere in grado di scriverci. Usa la direttiva create MODE OWNER GROUP per specificare i permessi corretti.

FAQ — Domande Frequenti

Devo riavviare il servizio dopo la modifica di logrotate?

No, non è necessario riavviare il servizio logrotate stesso. Le modifiche ai file di configurazione in /etc/logrotate.d/ vengono lette ogni volta che logrotate viene eseguito dal cronjob giornaliero. Tuttavia, se hai modificato il blocco postrotate per un’applicazione specifica, potresti voler forzare una rotazione con sudo logrotate -f /etc/logrotate.d/app per assicurarti che il comando postrotate venga eseguito e testato immediatamente.

Qual è la differenza tra compress e delaycompress?

compress comprime immediatamente il log file appena ruotato. delaycompress ritarda la compressione di un ciclo di rotazione. Questo significa che il file app.log.1 (il log appena ruotato) rimarrà non compresso fino alla prossima esecuzione di logrotate, quando verrà compresso in app.log.1.gz. È utile per servizi che potrebbero ancora leggere dal file appena ruotato per un breve periodo, evitando errori di accesso a file compressi.

Posso usare logrotate per ruotare i log di Docker?

Sì, è possibile. I log di Docker sono solitamente gestiti tramite il driver di logging configurato per i container. Tuttavia, se i tuoi container scrivono log su file sul filesystem dell’host, puoi configurare logrotate per quei file. Un approccio comune è configurare il driver di logging di Docker (es. json-file con max-size e max-file) e poi usare logrotate per gestire i log del demone Docker stesso, che si trovano tipicamente in /var/lib/docker/containers/ o simili.

Come posso escludere un certo tipo di log dalla rotazione?

logrotate permette di specificare pattern di inclusione ed esclusione. Se hai un pattern generico come *.log ma vuoi escludere debug.log, puoi usare la direttiva tabooext nel file di configurazione principale /etc/logrotate.conf oppure un file di configurazione specifico con un pattern più preciso per l’inclusione. In generale, è meglio essere specifici con i pattern di inclusione per evitare rotazioni indesiderate.

Conclusioni con takeaway operativi

La corretta configurazione di logrotate è un’operazione che, una volta impostata, ti risparmierà innumerevoli mal di testa legati a dischi pieni e perdita di dati. Ricorda sempre di:

1. Creare file di configurazione dedicati per ogni applicazione in /etc/logrotate.d/.
2. Scegliere attentamente tra copytruncate e create, in base al comportamento del tuo servizio.
3. Implementare sempre un blocco postrotate per far riaprire i log ai servizi quando usi create.
4. Testare ogni nuova configurazione con sudo logrotate -d prima di applicarla in produzione.
5. Monitorare il file /var/lib/logrotate/status per assicurarti che le rotazioni avvengano regolarmente.

Una gestione proattiva dei log non è solo una buona pratica, ma un requisito indispensabile per la stabilità e la sicurezza di qualsiasi infrastruttura Linux.

Fonti

• logrotate man page
• Systemd documentation

Aggiornato: Ottobre 2026