Che cosa succede al lavoro del tuo sito se la macchina è spenta

Se un lavoro del sito deve partire a un'ora fissata, una copia, un rapporto o una pulizia, la domanda è che cosa succede quando la macchina è spenta a quell'ora, e come si vede se è partito. Il 3 novembre 2026 ho letto quattro pagine di systemd 262, tre pagine di cronie, e tre pagine già online. Non dicono la stessa cosa. Non ho eseguito un timer e non ho eseguito un crontab.

Le pagine già online

La pagina su reload e daemon-reload risponde a quale comando fa applicare una modifica. Una frase è il ricaricamento del programma già in esecuzione. L'altra è il ricaricamento, da parte del gestore, dei file di unit. Non nomina un lavoro a un'ora fissata, un calendario, né che cosa succede se la macchina è spenta. Non la riscrivo. Il servizio non applica la modifica: reload o daemon-reload.

La pagina su Restart= risponde a perché il servizio del sito non torna su dopo un errore. Parla di uscita pulita, di errore, di segnale e di timeout, e di che cosa lasciano stare lo stop e il limite. Non parla di un orario, né di un lavoro che doveva partire mentre la macchina era spenta. Non la riscrivo. Perché il servizio del tuo sito non torna su dopo un errore.

La pagina su Type= risponde a quando il servizio risulta avviato. simple e notify sono due modi di dirlo. Non dicono quando un lavoro periodico deve partire, né come si guarda l'esito di ieri. Non la riscrivo. Type=simple e Type=notify: quando il servizio risulta avviato.

Il file che segna l'ora

La pagina systemd.timer ha in testa systemd 262. Last-modified della risposta: 22 settembre 2026 alle 13:31:36 GMT. La risposta letta il 3 novembre 2026 porta la data 06:18:12 GMT. Sono due date. Il 22 settembre non è il 3 novembre. Non li unisco. Indirizzo: https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html.

Un file di unit il cui nome finisce in .timer descrive un timer controllato da systemd, per un avvio basato sul tempo. Per ogni file timer deve esistere una unit corrispondente, quella da avviare quando il timer scade. Di default si avvia un servizio con lo stesso nome del timer, salvo il suffisso. L'esempio della pagina è un timer e il servizio omonimo. La unit da avviare si può indicare con Unit=. Stesso nome, e Unit=, sono due frasi. Non le unisco.

Se la unit da avviare è già attiva nel momento in cui il timer scade, non viene riavviata: resta in esecuzione. Non c'è, in quel caso, l'idea di creare nuove istanze del servizio. Un servizio con RemainAfterExit=yes, che resta anche dopo l'uscita del processo principale, di solito non va bene per un timer che si ripete: si attiva una volta e poi resta. Sono due frasi della stessa pagina. Non sono la riga Restart= dell'altra pagina, e non la riscrivo.

Se la macchina era spenta

Persistent= prende un valore booleano. Se è vero, l'ora in cui la unit di servizio è stata avviata l'ultima volta viene scritta su disco. Quando il timer viene attivato, la unit di servizio parte subito se sarebbe partita almeno una volta nel tempo in cui il timer era inattivo. Questo avvio resta comunque soggetto al ritardo di RandomizedDelaySec=. La pagina dice che serve a recuperare le esecuzioni mancate del servizio quando il sistema era spento. Questa impostazione ha effetto solo sui timer configurati con OnCalendar=. Il predefinito è falso. Aggiunta nella versione 212.

Vero, almeno una volta, ritardo casuale, solo calendario, predefinito falso, versione 212: sono frasi distinte. Il 212 non è il 262 dell'intestazione. Non li unisco. Non deduco, dal predefinito falso, una frase che la pagina non scrive. La pagina non dice, in questo capoverso, che il caso falso esegua il lavoro. Non lo aggiungo.

La stessa pagina, più sopra, parla di un altro caso. Se un timer configurato con OnBootSec= o OnStartupSec= è già nel passato quando la unit del timer viene attivata, scade subito e la unit configurata parte. Per i timer definiti nelle altre direttive non è così. Già nel passato all'attivazione, e recupero mentre il timer era inattivo, non sono la stessa frase. Non li unisco. L'argomento di OnBootSec= è un intervallo, e l'esempio della pagina è 50 secondi dopo l'avvio, oppure 5 ore e 30 minuti. Sono esempi della pagina. Non sono l'orario di un sito.

Un'altra frase dice che, se il computer è sospeso per un po', l'orologio monotonico in genere si ferma anche lui. La sospensione non è lo spento del capoverso su Persistent=. Non li unisco. Non ho provato un portatile.

OnCalendar= definisce timer sull'orologio da parete, con espressioni di calendario. I timer non scadono per forza all'istante preciso configurato: dipendono da AccuracySec=. Si può indicare più di una volta, e il timer scatta quando scade una qualunque delle espressioni. Precisione, e più espressioni, sono due frasi. Non le unisco al recupero a macchina spenta.

Il calendario, senza i segni

La pagina systemd.time ha la stessa intestazione systemd 262. Last-modified: 22 settembre 2026 alle 13:31:36 GMT, lo stesso secondo della pagina del timer. La risposta letta il 3 novembre 2026 porta la data 06:18:13 GMT, un secondo dopo. Stesso secondo di modifica, risposte a un secondo di distanza: sono due documenti. Non li unisco. Indirizzo: https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html.

Dice che in systemd istanti, durate ed eventi di calendario usano sintassi vicine. Gli eventi di calendario sono usati dalle unit timer, e rimanda a systemd.timer. Il comando calendar di systemd-analyze valida e normalizza un'espressione, e calcola quando l'evento capiterebbe la prossima volta. Non l'ho eseguito.

In fondo la pagina normalizza alcune parole. hourly e daily sono due di quelle parole. Le espressioni normalizzate, nella tabella, usano un segno. Non copio quelle espressioni. Non copio nemmeno l'esempio aritmetico delle durate. Le parole hourly e daily restano nomi della pagina. Non sono un orario che ho misurato.

Il minuto corrente di crontab

La pagina crontab è del progetto cronie. In calce: cronie 2012-11-22. Il colophon dice che la pagina è stata presa dal repository Git il 3 agosto 2026. In quel momento il commit più recente trovato nel repository è del 5 dicembre 2025. La resa HTML è del 9 settembre 2026. Last-modified della risposta: 2 novembre 2026 alle 20:20:30 GMT. La risposta letta il 3 novembre 2026 porta la data 06:18:11 GMT. Sono cinque date. Il 22 novembre 2012, il 5 dicembre 2025, il 3 agosto 2026, il 9 settembre 2026 e il 2 novembre 2026 non sono lo stesso giorno. Non li unisco. Indirizzo: https://man7.org/linux/man-pages/man5/crontab.5.html.

Un file crontab contiene istruzioni per il demone cron: eseguire questo comando a quest'ora in questa data. Ogni utente può avere il suo. I comandi di un crontab girano con l'utente che possiede quel crontab.

Il formato di un comando cron ha cinque campi di data e ora, poi un nome utente se il file è quello di sistema, poi un comando. Il nome utente condizionato al file di sistema, e il comando, non sono la stessa casella. I lavori nella directory dei lavori di sistema e nel file di crontab di sistema sono lavori di sistema, e lì il nome utente serve in più. La pagina scrive i due percorsi. Non li copio. È un'altra frase, più sotto. Non la unisco alla parentesi della prima.

I comandi sono eseguiti da cron quando i campi minuto, ora e mese dell'anno coincidono con l'ora corrente, e almeno uno dei due campi giorno, giorno del mese oppure giorno della settimana, coincide con l'ora corrente. cron esamina le voci ogni minuto. I valori ammessi sono: minuto da 0 a 59, ora da 0 a 23, giorno del mese da 1 a 31, mese da 1 a 12, giorno della settimana da 0 a 7. 0 o 7 è domenica. Almeno uno dei due giorni, e l'esame ogni minuto, sono due frasi. Non le unisco.

Un campo può contenere un segno che sta sempre per primo-ultimo. Non copio il segno. Gli intervalli sono due numeri separati da un trattino, estremi inclusi. L'esempio della pagina, 8-11 nel campo delle ore, è l'esecuzione alle ore 8, 9, 10 e 11. È l'esempio della pagina. Non è l'orario di un sito.

La nota dice che il giorno di esecuzione si può indicare in due campi, giorno del mese e giorno della settimana. Se entrambi sono ristretti, cioè non contengono quel segno, il comando parte quando uno dei due coincide con l'ora corrente. L'esempio della pagina farebbe partire un comando alle 4 e 30 del mattino, il giorno 1 e il giorno 15 di ogni mese, e anche ogni venerdì. Non copio la riga dell'esempio: contiene il segno. La frase "almeno uno", più sopra, e questo "uno dei due" quando entrambi sono ristretti, restano due punti. Non ho, in queste righe, una frase separata per il caso in cui uno solo dei due campi sia ristretto. Non la invento.

La stessa descrizione dice che gli orari inesistenti, come le ore mancanti nel cambio dell'ora legale, non coincidono mai, e quindi i lavori previsti in quegli orari non partono. Gli orari che capitano più di una volta, ancora per il cambio dell'ora, fanno partire due volte i lavori che coincidono. Ore mancanti, e ora doppia, sono due frasi. Non sono la macchina spenta. Non li unisco al recupero del timer.

Il sesto campo è il comando. La pagina dice che la parte di comando, fino a un a capo o a un segno di percentuale, viene eseguita da una shell, oppure dalla shell indicata nella variabile SHELL del file. Nomina un percorso predefinito. Non lo copio. Un segno di percentuale nel comando, se non è preceduto da una barra rovesciata, diventa un a capo, e tutto ciò che segue il primo va al comando come ingresso. Percentuale, e percorso della shell, sono due frasi. Non le unisco.

Se l'utente proprietario ha UID 0, il primo carattere di una voce può essere un trattino. Quel trattino impedisce a cron di scrivere un messaggio di syslog sul comando eseguito. È una frase sul messaggio di esecuzione, non sull'esito che arriva per posta. Non li unisco.

Sulla posta, la stessa pagina distingue tre casi. Se MAILTO è definita e non è vuota, la posta va all'indirizzo indicato. Se MAILTO è definita ma vuota, non si manda posta. Altrimenti la posta va al proprietario del crontab. Definita e piena, definita e vuota, assente: sono tre frasi. Non le unisco. MAILFROM, se definita e non vuota, è il mittente della busta. Altrimenti si usa il nome dell'utente che esegue. È un'altra coppia. Non la unisco ai tre casi di MAILTO.

Che cosa fa il demone cron

La pagina cron è un altro documento dello stesso progetto. In calce: cronie 2013-09-26. Il 26 settembre 2013 non è il 22 novembre 2012 della pagina crontab. Il colophon ha le stesse tre date di prelievo: repository del 3 agosto 2026, commit trovato del 5 dicembre 2025, resa HTML del 9 settembre 2026. Last-modified: 2 novembre 2026 alle 20:20:30 GMT, lo stesso secondo. Risposta delle 06:18:11 GMT, lo stesso secondo. Stesse date di prelievo, calendari in calce diversi: sono due pagine. Non li unisco. Indirizzo: https://man7.org/linux/man-pages/man8/cron.8.html.

Quando systemd è abilitato, il file di unit è installato e il demone si avvia con il comando di avvio di systemctl sulla unit crond.service. È una unit di servizio. Non è un file .timer. Non la tratto come la schedulazione descritta da systemd.timer.

Cron esamina tutti i crontab tenuti in memoria e controlla ogni lavoro per vedere se deve essere eseguito nel minuto corrente. Quando esegue i comandi, qualunque uscita viene mandata per posta al proprietario del crontab, oppure all'utente indicato in MAILTO se questa variabile c'è. Qualunque uscita del lavoro può anche essere mandata a syslog con l'opzione -s. Minuto corrente, posta, e syslog con -s, sono tre frasi. La posta di questa pagina non elenca il caso della variabile definita ma vuota. Quel caso sta sulla pagina crontab. Non li unisco.

Ci sono due modi per accorgersi che un crontab è cambiato. Il primo controlla l'ora di modifica del file. Il secondo usa inotify. Con l'ora di modifica, cron controlla ogni minuto e ricarica i file cambiati. La pagina dice che non serve riavviare cron dopo che alcuni crontab sono stati modificati. L'uso di inotify viene scritto in un log dopo l'avvio del demone. La pagina scrive il percorso di quel log. Non lo copio. Ricarica senza riavvio, e riga di log sull'inotify, sono due frasi. Non sono daemon-reload di un file .timer. Quella frase sta più sotto, e solo per il file del timer.

La stessa pagina dice che cron cerca anche il file di anacron e i file nella directory dei lavori di sistema, che hanno un formato diverso, e rimanda a crontab. I percorsi stanno sulla pagina. Non li copio. Il formato diverso non è la descrizione del comportamento di anacron. Non li unisco.

Anacron non assume la macchina accesa

La pagina anacron è un terzo documento. In calce: cronie 2012-11-22, la stessa data in calce della pagina crontab e non quella della pagina cron. Prelievo del 3 agosto 2026, commit del 5 dicembre 2025, resa del 9 settembre 2026, last-modified alle 20:20:30 GMT, risposta delle 06:18:11 GMT. Stesso secondo delle altre due risposte man7. Tre documenti, non una copia. Indirizzo: https://man7.org/linux/man-pages/man8/anacron.8.html.

Anacron esegue comandi a intervalli, con una frequenza indicata in giorni. A differenza di cron, non assume che la macchina resti accesa di continuo. Per questo si può usare su macchine che non stanno accese 24 ore su 24, per lavori quotidiani, settimanali e mensili. "A differenza di cron" è la frase di questa pagina. Non è una frase che ho trovato sulla pagina cron. Non sposto il soggetto.

Ogni voce indica un periodo in giorni, un'attesa in minuti, un identificatore unico e un comando di shell. Per ogni lavoro, anacron controlla se è stato eseguito negli ultimi n giorni, dove n è il periodo di quel lavoro. Se non è stato eseguito da n giorni o più, esegue il comando dopo aver atteso i minuti indicati come attesa. Dopo l'uscita del comando, registra la data, ora esclusa, in un file di timestamp di quel lavoro. Quando non restano lavori da eseguire, anacron esce. Periodo in giorni, attesa in minuti, data senza l'ora, e uscita del programma: sono quattro frasi. Non le unisco. Non le chiamo Persistent=.

Se il lavoro produce uscita sullo standard output o sullo standard error, l'uscita viene mandata per posta all'utente con cui anacron gira, di solito root, oppure all'indirizzo in MAILTO nel file di configurazione di anacron, se c'è. La pagina scrive il percorso di quel file. Non lo copio. Non ho aperto la pagina del formato. La posta di anacron e i tre casi di MAILTO sulla pagina crontab restano pagine diverse. Non li unisco.

Non sono la stessa frase

Sulla pagina cron il controllo è il minuto corrente. Sulla pagina crontab l'esame è ogni minuto, e l'esecuzione chiede che minuto, ora e mese coincidano con l'ora corrente. Nessuna delle due descrive il recupero di un minuto già passato mentre la macchina era spenta. Non aggiungo quel recupero.

Sulla pagina anacron la differenza è esplicita: non assume la macchina accesa di continuo, e guarda se il lavoro manca da n giorni o più. La data registrata esclude l'ora. n giorni non è un minuto. Non lo trasformo nel minuto di cron.

Sulla pagina del timer il recupero, quando il sistema era spento, sta nel caso Persistent= vero, solo per OnCalendar=, ed è soggetto al ritardo casuale. Il predefinito è falso. Il caso OnBootSec= già nel passato è un'altra frase, e la sospensione che ferma l'orologio monotonico è una terza. Non ne faccio un'unica regola della macchina spenta.

Come capire se il lavoro è partito

La pagina systemctl ha in testa systemd 262. Last-modified: 22 settembre 2026 alle 13:31:35 GMT, un secondo prima delle pagine timer e time. La risposta letta il 3 novembre 2026 porta la data 06:18:14 GMT. Non unisco il secondo 35 con il secondo 36, né con le 06:18:14. Indirizzo: https://www.freedesktop.org/software/systemd/man/latest/systemctl.html.

list-timers elenca le unit timer attualmente in memoria, ordinate per il momento in cui scadono la prossima volta. La pagina spiega sei colonne. NEXT è la prossima volta che il timer partirà. LEFT è quanto manca. LAST è l'ultima volta che il timer è partito. PASSED è quanto tempo è passato da quell'ultima volta. UNIT è il nome del timer. ACTIVATES è il nome del servizio che il timer avvia quando parte. L'esempio stampato dalla pagina porta date del febbraio 2017. Sono date dell'esempio. Non le ho lette su una macchina. LAST dice quando è partito il timer. Non dice il codice con cui è uscito il servizio. Non invento quel codice. La voce è stata aggiunta nella versione 209. Il 209 non è il 212 di Persistent=, e non è il 262 dell'intestazione.

La pagina journalctl ha in testa systemd 262. Last-modified: 22 settembre 2026 alle 13:31:34 GMT. La risposta letta il 3 novembre 2026 porta la data 06:18:16 GMT. Due secondi dopo systemctl, e il last-modified è un secondo prima. Non li unisco. Indirizzo: https://www.freedesktop.org/software/systemd/man/latest/journalctl.html.

Senza parametri mostra il contenuto del registro accessibile a chi lo chiama. L'opzione che restringe i messaggi a una unit mostra i messaggi della unit indicata, per esempio una unit di servizio, oppure delle unit che corrispondono a un modello. La pagina scrive quell'opzione con due trattini. Non li copio. Per ogni nome di unit aggiunge una corrispondenza per i messaggi della unit, e in più corrispondenze per i messaggi di systemd e per i messaggi sul dump di quella unit. Tre corrispondenze. Non le unisco in un unico esito. La voce è stata aggiunta nella versione 195. Il 195 non è il 209 di list-timers. La pagina non dice che questi messaggi siano il codice di uscita del lavoro. Non lo aggiungo.

Per cron, l'esito che le pagine descrivono è un altro canale. Sulla pagina crontab la posta ha tre casi, e il caso vuoto non manda nulla. Sulla pagina cron l'uscita va al proprietario o a MAILTO se c'è, e con l'opzione corta va a syslog. Sulla pagina anacron l'uscita va per posta all'utente del programma o a MAILTO del suo file di configurazione. Il log in cui la pagina cron scrive l'uso di inotify, dopo l'avvio, non è la colonna LAST. Il percorso di quel log sta sulla pagina. Non lo copio. Quattro posti. Non li unisco, e non li chiamo list-timers.

Se si modifica il file del timer

daemon-reload, sulla pagina systemctl di oggi, ricarica la configurazione del gestore systemd. Riesegue i generatori, ricarica tutti i file di unit e ricostruisce l'intero albero delle dipendenze. Mentre il demone si ricarica, i socket su cui systemd ascolta per la configurazione dell'utente restano raggiungibili. Questo comando non va confuso con reload. La frase vale per il caso in cui si modifica il file della unit del timer: il gestore ricarica i file di unit. Non è il ricaricamento del programma del sito. La pagina già online resta su quel confine, e non la riscrivo. Non ho eseguito il comando.

Sulla pagina cron, se cambia un crontab e si usa il controllo dell'ora di modifica, non serve riavviare cron. È la frase di quella pagina, sui file crontab. Non è daemon-reload. Non li unisco.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so se all'ora prevista la macchina era spenta, né se il lavoro sarebbe stato un minuto di cron, un periodo di anacron o un timer con Persistent= vero o falso. prova.bottega.example è l'altro nome. Non l'ho aperto. Non so se il lavoro è partito, se la posta è partita, se LAST avrebbe avuto una data, né che cosa ci sarebbe stato nel registro.

Non assegno a questi nomi le 4 e 30, il giorno 1, il giorno 15, il venerdì, le ore da 8 a 11, 50 secondi, 5 ore e 30 minuti, n giorni, una data del febbraio 2017, né un codice di uscita. I numeri restano quelli delle pagine lette.

Che cosa questa pagina lascia stare

Non ho eseguito un timer, un crontab, anacron, list-timers o journalctl. Non ho aperto anacrontab, crontab nella sezione 1, né systemd.unit. Non ho aperto di nuovo systemd.service: Restart= e Type= restano sulle loro pagine. Non ho copiato le righe di esempio che portano il segno, né il percorso della shell. La copertina è nuova, perché la pagina è nuova.

Non ho riscritto la pagina su reload e daemon-reload, la pagina su Restart=, la pagina su Type=, la pagina sul disco, la pagina sul primo byte, la pagina sugli spostamenti, la pagina sulle misure, la pagina su Server-Timing, la mappa di DNS, hosting e CDN, la pagina sulla connessione lunga, la pagina sul lavoro lungo, la pagina sulla copia di prova, la pagina sulla chiave, la pagina sulla compressione e la pagina sulla cartella. Le chiavi di un servizio esterno non sono questa pagina. Non l'ho scritta.

Fonti lette il 3 novembre 2026. systemd.timer, systemd 262, last-modified 22 settembre 2026 alle 13:31:36 GMT, risposta delle 06:18:12 GMT, Persistent= aggiunto nella 212, https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html. systemd.time, stessa intestazione 262, stesso last-modified alle 13:31:36 GMT, risposta delle 06:18:13 GMT, https://www.freedesktop.org/software/systemd/man/latest/systemd.time.html. systemctl, intestazione 262, last-modified alle 13:31:35 GMT, risposta delle 06:18:14 GMT, list-timers aggiunto nella 209, https://www.freedesktop.org/software/systemd/man/latest/systemctl.html. journalctl, intestazione 262, last-modified alle 13:31:34 GMT, risposta delle 06:18:16 GMT, l'opzione della unit aggiunta nella 195, https://www.freedesktop.org/software/systemd/man/latest/journalctl.html. crontab, cronie 2012-11-22, prelievo del 3 agosto 2026, commit del 5 dicembre 2025, resa del 9 settembre 2026, last-modified 2 novembre 2026 alle 20:20:30 GMT, risposta delle 06:18:11 GMT, https://man7.org/linux/man-pages/man5/crontab.5.html. cron, cronie 2013-09-26, stesse date di prelievo, stesso last-modified e stessa risposta delle 06:18:11 GMT, https://man7.org/linux/man-pages/man8/cron.8.html. anacron, cronie 2012-11-22, stesse date di prelievo e lo stesso secondo di risposta, https://man7.org/linux/man-pages/man8/anacron.8.html. Pagine già online, non riscritte: reload e daemon-reload, Restart=, Type=.