Cos'è systemd e cosa sono i timer (l'alternativa moderna a cron)

Un server Linux non è mai davvero fermo: dietro le quinte decine di programmi partono all’avvio, restano in ascolto e vengono riavviati se qualcosa va storto. Qualcuno deve coordinare tutto questo, decidere cosa avviare e in che ordine, e cosa fare quando un programma smette di funzionare. Su gran parte dei sistemi Linux moderni quel “qualcuno” si chiama systemd. Capire cos’è, e cosa sono i suoi timer, aiuta a ragionare su come una macchina Linux fa girare i propri servizi e pianifica le attività ricorrenti.

Cos’è systemd

La documentazione ufficiale lo definisce in modo asciutto: systemd è “un gestore di sistema e di servizi per sistemi operativi Linux”. In pratica è il primo programma che parte all’accensione, tecnicamente il processo numero 1 (o PID 1), e da lì avvia e mantiene in vita tutti gli altri. È quello che in gergo si chiama init system: il capostipite da cui discende ogni altro processo del sistema.

Serve una parola su cosa si intende per “servizio”. Un servizio (o daemon) è un programma che gira in sottofondo senza un’interfaccia con cui interagire direttamente: il web server che risponde alle pagine, il database, il sistema che invia le email. Non lo si “apre” come un’app: parte da solo e resta attivo. Il compito di systemd è avviare questi programmi nell’ordine giusto, tenerli d’occhio e, quando serve, riavviarli.

systemd è adottato dalla maggior parte delle distribuzioni Linux più diffuse, ed è per questo che conoscerlo anche solo a grandi linee è utile: è il punto di partenza per capire come una macchina Linux si comporta all’avvio e durante il funzionamento.

Le unit: i mattoncini di systemd

Tutto ciò che systemd gestisce è descritto da un’unit. Un’unit è semplicemente un file di testo che descrive un oggetto del sistema e come trattarlo. La documentazione ne elenca undici tipi diversi; per farsi un’idea bastano i più comuni:

le unit .service avviano e controllano i servizi (i daemon di cui sopra);
le unit .socket gestiscono le connessioni di rete o locali;
le unit .mount si occupano dei punti di montaggio dei dischi;
le unit .target raggruppano altre unit o segnano tappe note dell’avvio (per esempio “il sistema è pronto per la rete”);
le unit .timer, tema di questo articolo, fanno scattare l’attivazione di altre unit in base al tempo.

Il vantaggio di questo schema è l’uniformità. Che si tratti di un disco, di un servizio o di un’attività pianificata, la logica è sempre la stessa: un file che descrive l’oggetto e un unico insieme di comandi per gestirlo.

Cosa sono i timer

Ecco il punto chiave, spiegato con calma. Un timer di systemd non esegue un comando: fa partire un’altra unit a un certo momento. Per convenzione un timer attiva il servizio con lo stesso nome (backup.timer fa partire backup.service), e il lavoro vero, cioè il comando da eseguire, sta in quel servizio. Il timer dice soltanto quando.

I timer si dividono in due famiglie.

I timer di calendario scattano a un orario dell’orologio, come “ogni giorno alle 3:30 ”. Si configurano con l’opzione OnCalendar=, la cui sintassi ricalca l’idea dei campi di cron ma in forma più esplicita: giorno della settimana, anno-mese-giorno, ora:minuto:secondo . Un asterisco significa “qualsiasi valore”.

OnCalendar=*-*-* 03:30:00    # ogni giorno alle 3:30
OnCalendar=Mon..Fri 09:00    # dal lunedì al venerdì alle 9:00

Esistono anche scorciatoie comode come hourly, daily, weekly, monthly: per esempio daily corrisponde a *-*-* 00:00:00.

I timer monotonici, invece, non guardano l’orologio ma il tempo trascorso da un evento: OnBootSec= misura da quando la macchina è accesa, OnUnitActiveSec= da quando l’unit collegata è stata avviata l’ultima volta. Servono per esprimere cose come “15 minuti dopo l’avvio, poi ogni ora”.

Cos’è cron e perché si parla di alternativa

Per capire perché i timer piacciono, serve ricordare cosa fa cron. cron è il programma storico di Linux (e Unix) per pianificare attività ricorrenti: un daemon che, con le parole del suo manuale, “esegue questo comando a quest’ora in questa data”. La pianificazione si scrive in un file, la crontab, con cinque campi che indicano minuto, ora, giorno del mese, mese e giorno della settimana.

cron fa una cosa sola, e la fa da decenni con affidabilità: esegue un comando a un orario. Il punto è tutto il resto, cioè dove finisce l’output, cosa succede se la macchina era spenta all’orario previsto, come sapere quando ripartirà. Sono aspetti che a cron non competono. I timer di systemd nascono proprio per coprire quel “resto”.

I vantaggi dei timer

I log finiscono nel journal

systemd tiene un registro centralizzato degli eventi, il journal, gestito da un servizio chiamato journald. Per impostazione predefinita l’output di ogni servizio, sia quello normale sia i messaggi di errore, viene raccolto lì e ordinato per unit. Con cron, tradizionalmente, l’output di un’attività veniva spedito per email (tramite l’opzione MAILTO) o rischiava di perdersi. Con un timer basta un comando per rileggere l’intera storia di un’attività:

journalctl -u backup.service     # storico completo del job
systemctl list-timers            # tutti i timer e la prossima esecuzione

Recuperare le esecuzioni perse

Con cron, se la macchina era spenta all’orario previsto, quel giro salta e nessuno lo registra. I timer offrono l’opzione Persistent=true: systemd salva su disco quando l’attività è stata eseguita l’ultima volta e, alla riaccensione, se nel frattempo sarebbe dovuta partire almeno una volta, la avvia subito. È un comportamento pensato per recuperare le esecuzioni perse dopo un periodo di spegnimento, e vale per i timer di calendario.

Dipendenze e ordine

Un timer avvia un’unit, e un’unit vive nel grafo delle dipendenze di systemd. Si può quindi chiedere di eseguire un’attività “solo dopo che la rete è pronta” oppure “solo dopo che un disco è montato”. cron, invece, scatta all’orario e basta, che le condizioni siano soddisfatte o no.

Verificabilità

C’è un ultimo vantaggio pratico: si può controllare tutto senza aspettare l’orario. systemctl list-timers mostra ogni timer con la sua prossima esecuzione, e il servizio collegato si può avviare a mano per provarlo, indipendentemente dalla pianificazione.

Quando cron va ancora bene

Non è una gara. Per un’attività semplice, senza bisogno di log strutturati, dipendenze o recupero, cron resta più breve da scrivere ed è disponibile anche su sistemi che non usano systemd. Ma quando conta sapere cosa è successo, cioè l’output, l’esito e la prossima esecuzione, oppure servono ordine e recupero dopo un’interruzione, i timer offrono molto di più a fronte di un file in più da scrivere.

In sintesi

systemd è il gestore di sistema e servizi che, su gran parte dei Linux moderni, avvia e sorveglia i programmi della macchina. Descrive ogni cosa come un’unit, e tra queste ci sono i timer: un modo per pianificare attività ricorrenti che, rispetto a cron, aggiunge log integrati nel journal, recupero delle esecuzioni perse e dipendenze. cron non è obsoleto, ma per chi ha bisogno di sapere davvero cosa fanno i propri job pianificati, i timer sono l’alternativa moderna.

# Cos'è systemd e cosa sono i timer (l'alternativa moderna a cron)