In breve
Per attività semplici e non critiche cron va benissimo. Per job il cui fallimento qualcuno deve notare, come backup, rinnovo certificati o job in background di Nextcloud, i timer systemd sono di solito la scelta migliore, perché stato e log sono visibili con systemctl e journalctl.
| Criterio | systemd timers | cron |
|---|---|---|
| Configurazione | Due unit: .service e .timer | Una riga nella crontab |
| Pianificazione | OnCalendar=, es. *-*-* 03:00, o relativa con OnBootSec= | Cinque campi, es. 0 3 * * * |
| Log | Automatici nel journal, con journalctl -u | Solo via mail (MAILTO) o redirezione tua |
| Esecuzioni perse | Persistent=true le recupera dopo l'avvio | Perse (salvo con anacron) |
| Sovrapposizione | Se il servizio è ancora attivo, il timer non lo riavvia | Possibile, da evitare per esempio con flock |
| Ambiente | Definito nella unit, riproducibile | PATH minimo, fonte frequente di errori |
| Risorse e sicurezza | Limiti di CPU, memoria e I/O, sandboxing con le opzioni della unit | Niente di integrato |
| Panoramica | systemctl list-timers mostra ultima e prossima esecuzione | crontab -l per utente, più /etc/cron.d |
Scegli systemd timers se …
- un errore deve emergere, per esempio nel monitoraggio delle unit fallite.
- il job dura a lungo e non deve sovrapporsi a se stesso.
- la macchina non è sempre accesa e le esecuzioni perse vanno recuperate.
- vuoi limitare le risorse o far girare il job con privilegi ridotti.
Scegli cron se …
- l'attività è breve, semplice e non critica.
- gestisci sistemi senza systemd, come container o distribuzioni più vecchie.
- l'applicazione documenta una riga di crontab e vuoi restare vicino alla documentazione.
- gli utenti devono gestire i propri job senza permessi di root.
Insidie dal lavoro quotidiano
- Cron: lo script funziona da terminale ma non da cron. Quasi sempre è colpa di
PATHo di variabili mancanti. Usa percorsi assoluti. - Cron: un
%nella riga di comando viene letto come a capo e va scritto\%, per esempio indate +%F. - systemd: dopo aver creato le unit mancano
systemctl daemon-reloadesystemctl enable --now nome.timer. Il timer esiste ma non parte mai. - systemd: verifica prima le espressioni
OnCalendarconsystemd-analyze calendar, altrimenti il job gira in orari diversi da quelli previsti.
Domande frequenti
Devo convertire tutti i cron job in timer?
No. Conviene per i job il cui fallimento ha conseguenze o che vuoi monitorare. I job di pulizia semplici possono restare in cron. L'importante è che ogni attività sia definita in un solo posto.
Come vedo se un timer è andato a buon fine?
systemctl list-timers mostra l'ultima esecuzione, systemctl status nome.service il risultato e journalctl -u nome.service l'output. Le esecuzioni fallite compaiono anche in systemctl --failed.