Timer Systemd vs. Cron: Scegliere lo Scheduler Giusto

Quando il tuo server Linux deve eseguire un backup, una pulizia, un controllo di integrità o un report secondo una pianificazione, di solito scegli tra cron e i timer systemd. Cron è ancora semplice e portabile. I timer systemd sono più adatti quando il lavoro si comporta come un servizio gestito e necessita di log, dipendenze o controlli delle risorse.

La scelta giusta dipende dalla macchina su cui esegui, dal comportamento del lavoro in caso di errore e dalla quantità di visibilità operativa di cui hai bisogno.

Comprendere i Job Cron

cron è un pianificatore di job basato sul tempo nei sistemi operativi simili a Unix. Permette agli utenti di pianificare comandi o script da eseguire periodicamente a orari, date o intervalli fissi. Il demone cron (crond) viene eseguito in background e controlla i file crontab per eventuali job pianificati.

Come Funziona Cron

Ogni utente può avere il proprio file crontab, gestito tramite il comando crontab. I job a livello di sistema sono tipicamente configurati in /etc/crontab o in file all'interno di /etc/cron.d/.

Una voce crontab segue un formato specifico:

* * * * * comando_da_eseguire
│ │ │ │ │
│ │ │ │ └───── Giorno della settimana (0 - 6) (Domenica=0 o 7)
│ │ │ └─────── Mese (1 - 12)
│ │ └───────── Giorno del mese (1 - 31)
│ └─────────── Ora (0 - 23)
└───────────── Minuto (0 - 59)

Esempio: Per eseguire uno script di backup ogni giorno alle 2:00:

0 2 * * * /usr/local/bin/backup.sh

Vantaggi di Cron

Onnipresente: Disponibile praticamente su tutti i sistemi simili a Unix.
Sintassi Semplice: Il formato crontab è relativamente facile da imparare per la pianificazione di base.
Job Specifici per Utente: Facile impostare job per singoli utenti.

Svantaggi di Cron

Flessibilità Limitata: Principalmente basato su intervalli di tempo fissi. Gestire dipendenze complesse o pianificazione basata su eventi è difficile.
Nessuna Gestione delle Dipendenze: Non può definire facilmente che un job debba essere eseguito solo dopo che un altro job è stato completato con successo.
Nessun Controllo delle Risorse: Offre poco o nessun controllo sulle risorse (CPU, memoria) consumate dai job pianificati.
Logging e Monitoraggio: Spesso si basa sull'output email, syslog o sul reindirizzamento esplicito nel comando.
Integrazione con File Unit: Non direttamente integrato con le capacità di gestione dei servizi di systemd.

Comprendere i Timer Systemd

I timer systemd sono un modo più avanzato e flessibile per pianificare attività, sfruttando la potenza dei file unit di systemd. Invece di un demone separato, i timer systemd sono gestiti come parte del sistema init systemd stesso.

Come Funzionano i Timer Systemd

I timer systemd sono composti da due file unit:

Unit di Servizio (.service): Definisce l'attività o il comando da eseguire.
Unit Timer (.timer): Definisce quando deve essere attivata la corrispondente unit di servizio.

Questi file sono tipicamente posizionati in /etc/systemd/system/ o ~/.config/systemd/user/.

Esempio: Pianificare uno script di pulizia da eseguire ogni giorno alle 3:00.

Prima, crea il file di servizio (cleanup.service):

# /etc/systemd/system/cleanup.service

[Unit]
Description=Attività di pulizia giornaliera

[Service]
Type=oneshot
ExecStart=/usr/local/bin/cleanup.sh

Successivamente, crea il file timer (cleanup.timer):

# /etc/systemd/system/cleanup.timer

[Unit]
Description=Esegui attività di pulizia giornaliera

[Timer]
# Esegui 25 minuti dopo l'avvio, e poi ogni giorno alle 3:00
OnBootSec=25min
OnCalendar=*-*-* 03:00:00
# Alternativa: Esegui 24 ore dopo l'ultima esecuzione
# OnUnitActiveSec=24h

[Install]
WantedBy=timers.target

Dopo aver creato questi file, ricarica systemd, abilita il timer per gli avvii futuri e avvialo ora:

sudo systemctl daemon-reload
sudo systemctl enable cleanup.timer
sudo systemctl start cleanup.timer

Puoi controllare lo stato del timer e quando si attiverà successivamente usando:

sudo systemctl status cleanup.timer

Direttive Chiave dei Timer `systemd`:

OnCalendar=: Specifica un orario di evento calendario (simile alla sintassi di cron ma più potente).
- *-*-* 03:00:00: Ogni giorno alle 3:00.
- Mon..Fri *-*-* 09:00:00: Giorni feriali alle 9:00.
- hourly: Ogni ora.
- daily: Una volta al giorno.
- weekly: Una volta a settimana.
- monthly: Una volta al mese.
- yearly: Una volta all'anno.
OnBootSec=: Attiva un tempo specificato dopo l'avvio del sistema.
OnUnitActiveSec=: Attiva un tempo specificato dopo l'ultima attivazione dell'unità corrispondente (servizio).
OnUnitInactiveSec=: Attiva un tempo specificato dopo che l'unità corrispondente (servizio) è diventata inattiva.
AccuracySec=: Quanto preciso deve essere il timer. Valori più bassi potrebbero consumare più energia.
Persistent=: Per i timer calendario, true dice a systemd di recuperare quando un'esecuzione pianificata è stata persa mentre il timer era inattivo, ad esempio quando la macchina era spenta.

Vantaggi dei Timer Systemd

Integrazione con systemd: Si integra perfettamente con la gestione dei servizi di systemd, il logging (journalctl), il controllo delle risorse e la gestione delle dipendenze.
Flessibilità: Supporta varie opzioni di pianificazione oltre agli intervalli fissi, inclusi eventi calendario, tempi relativi dopo l'avvio e tempi relativi dopo l'attivazione precedente.
Gestione delle Dipendenze: Può definire dipendenze da altre unit systemd (ad esempio, disponibilità della rete).
Controllo delle Risorse: Può sfruttare i cgroups di systemd per la limitazione delle risorse (CPU, memoria).
Logging: Integrato con journald per un logging completo e centralizzato.
Gestione degli Errori: Può utilizzare comportamenti delle unit di servizio come Restart=, OnFailure= e l'ordinamento delle dipendenze dove questi modelli si adattano al lavoro.
Consapevolezza dello Stato: Può tracciare quando un job avrebbe dovuto essere eseguito ed eseguirlo all'avvio del sistema se Persistent=true è impostato.

Svantaggi dei Timer Systemd

Curva di Apprendimento più Ripida: La sintassi e i concetti dei file unit di systemd possono essere più complessi di cron per i principianti.
Dipendenza da Systemd: Richiede un sistema che esegue systemd (la maggior parte delle distribuzioni Linux moderne lo fa).

Timer Systemd vs. Cron: Differenze Chiave Riassunte

Caratteristica	Job Cron	Timer Systemd
Gestione	Comando `crontab`, file di sistema	Comando `systemctl`, file unit
Pianificazione	Minuto, ora, giorno, mese, giorno settimana fissi	Eventi calendario, tempi relativi, basati su avvio
Integrazione	Demone autonomo	Integrato con `systemd`
Logging	Email, reindirizzamento script	`journald`
Dipendenze	Nessuna	Dipendenze unit `systemd`
Controllo Risorse	Nessuno	cgroups di `systemd`
Gestione Errori	Base	Gestione errori unit di servizio
Tracciamento Stato	Limitato	Opzione `Persistent=`
Complessità	Più semplice per attività di base	Più potente, curva di apprendimento più ripida

Quando Scegliere Quale Scheduler

Scegli Cron Quando:

Sei su un sistema molto vecchio o minimale che non utilizza systemd.
Devi pianificare un'attività molto semplice e una tantum con una pianificazione fissa e ricorrente, e dai priorità alla semplicità rispetto alle funzionalità avanzate.
Hai bisogno di una pianificazione rapida per un comando che gestisce già il proprio logging e i propri errori.

Scegli i Timer Systemd Quando:

Sei su una distribuzione Linux moderna che utilizza systemd.
Hai bisogno di più controllo su quando un job viene eseguito (ad esempio, rispetto all'avvio, rispetto all'ultima esecuzione, dopo che la rete è attiva).
Richiedi un logging, monitoraggio e gestione degli errori migliori.
Vuoi gestire l'esecuzione dei job con le potenti funzionalità di gestione dei servizi di systemd, inclusi il controllo delle risorse e la gestione delle dipendenze.
Stai già gestendo altri servizi con systemd e desideri un approccio coerente alla pianificazione.
Le tue attività hanno dipendenze da altri servizi di sistema o eventi.

Regola Pratica

Usa cron quando il job è un comando breve e ovvio e la portabilità è importante. Usa un timer systemd quando il job fa parte di un servizio, necessita dei log di journalctl, deve attendere la rete o beneficia di limiti di risorse e ordinamento delle dipendenze.

Un backup notturno è un buon esempio. Su un piccolo server legacy, 0 2 * * * /usr/local/bin/backup.sh potrebbe essere sufficiente. Su un host di produzione basato su systemd, un backup.service più backup.timer ti offre uno stato più chiaro, log, recupero all'avvio con Persistent=true e un percorso più pulito per aggiungere dipendenze in seguito.