Chiunque amministri sistemi Linux conosce bene quanto la pianificazione delle attività sia un tassello fondamentale del lavoro quotidiano. Backup, sincronizzazioni, rotazione dei log, aggiornamenti periodici, controlli di integrità: tutto ruota attorno a meccanismi schedulati che devono girare in modo affidabile per mesi, anni, senza che nessuno ci metta mano. Per decenni il punto di riferimento è stato uno solo, cron, arrivato nei sistemi Unix negli anni Settanta e ancora oggi diffusissimo. Eppure le distribuzioni moderne si appoggiano ormai a systemd, che nel tempo ha assorbito un sacco di funzioni di gestione, compresa proprio la pianificazione. Ed è qui che entrano in gioco i timer di systemd, spesso ignorati per pura abitudine.
La diffusione di systemd è praticamente capillare: Debian, Ubuntu, Fedora, RHEL, Arch Linux. Tutte si basano su questo componente. Nonostante ciò, molti continuano a scrivere crontab come si faceva vent’anni fa, senza accorgersi che esiste uno strumento più raffinato e affidabile a portata di mano.
Dove cron inizia a mostrare la corda
Cron fa il suo dovere, non c’è dubbio. Ma è nato in un’epoca in cui i sistemi Unix erano tutta un’altra cosa, e alcune sue caratteristiche oggi creano grattacapi. I job pianificati, per esempio, partono spesso con un ambiente ridotto all’osso e con un $PATH diverso da quello di una normale sessione interattiva. Risultato? Malfunzionamenti difficili da diagnosticare, di quelli che ti fanno perdere ore.
C’è poi la questione dell’output. Gli errori finiscono nei log di sistema oppure vengono spediti via email, una modalità che con le esigenze di monitoraggio attuali c’entra ben poco. E la sintassi, per quanto compatta, resta poco leggibile. Un’espressione come 15,45 02,14 5-20 3,9 un veterano la decifra al volo, ma richiede comunque un certo sforzo mentale.
Come lavora un timer systemd
Il meccanismo è elegante nella sua separazione dei compiti. Un timer è un’unità speciale che attiva un’altra unità, di solito un servizio. Il file .timer stabilisce il quando, il file .service contiene l’azione vera e propria. Un esempio minimo: un servizio con ExecStart=/usr/local/bin/mio-script.sh e un timer con OnCalendar=11:00, che lo manda in esecuzione ogni giorno alle 11. Questa divisione netta tra logica temporale e logica operativa porta una chiarezza che nelle vecchie configurazioni cron proprio non esiste.
Un timer può scattare una volta al giorno, ogni ora, dopo il boot, oppure a intervalli calcolati rispetto all’ultima esecuzione. I file vivono di solito in /etc/systemd/system, con la stessa architettura delle altre unità.
Tra i punti forti c’è la prevedibilità dell’ambiente. Nel file .service ogni comando va indicato col percorso assoluto, tipo ExecStart=/usr/bin/python3 /opt/scripts/report.py, eliminando ogni dubbio su dove si trovi il binario. Systemd non interpreta da solo pipe e reindirizzamenti: se servono, vanno richiamati esplicitamente via Bash. Sembra rigido, ma taglia alla radice una marea di errori legati alle differenze ambientali.
Interessante anche la gestione delle condizioni con ExecCondition=, che verifica un prerequisito prima di avviare il servizio. Se la condizione salta, systemd scrive il motivo nel journal senza costringere a interpretare codici di uscita criptici.
Funzioni che cron non ha mai avuto
Sul fronte della pianificazione, systemd distingue tra eventi a calendario e intervalli relativi. La modalità a calendario somiglia a cron: OnCalendar=daily significa esecuzione quotidiana a mezzanotte. La sintassi è espressiva, e con systemd-analyze calendar “daily” si verifica al volo cosa significa una regola e quando scatterà la prossima volta.
La pianificazione relativa, invece, lega tutto al trascorrere del tempo. Con OnBootSec=1h e OnUnitActiveSec=1h il servizio parte un’ora dopo l’avvio e poi ogni ora. Per certe manutenzioni, come la pulizia di /tmp, ha molto più senso così che ancorarsi a un minuto preciso.
Poi c’è la visibilità: con systemctl list-timers compare una tabella con prossima esecuzione, tempo rimanente, ultima esecuzione e servizio collegato. Un colpo d’occhio su tutto, altro che inseguire crontab sparse tra utenti diversi.
Cos’è WakeSystem=true?
Da segnalare anche WakeSystem=true, che risveglia il computer dalla sospensione per eseguire un servizio, perfetto per download notturni e backup. Le direttive RandomizedDelaySec= e RandomizedOffsetSec= aggiungono ritardi casuali controllati per evitare il thundering herd, cioè migliaia di macchine che partono nello stesso istante sovraccaricando l’infrastruttura. E con Persistent=true un backup programmato alle 4 del mattino non va perso se il computer era spento: alla prima accensione il servizio parte da solo, recuperando le esecuzioni mancate.
I timer di systemd non sono un semplice rimpiazzo di cron. Sono una reinterpretazione moderna della pianificazione, pensata per esigenze che decenni fa nemmeno esistevano. Cron resta affidabile e usatissimo, ma chi gestisce server, workstation o ambienti cloud trova nei timer un livello di controllo e osservabilità che con i vecchi job difficilmente si raggiunge.