Cosa sono le * * * * * delle cron? come impostare l'inizio e la ripetizione?

Cosa sono le cron e a cosa servono

Le cron sono il sistema classico di Linux e Unix per eseguire comandi in modo automatico a orari o intervalli definiti. In pratica, invece di lanciare manualmente uno script, si dice al sistema quando deve partire e quanto spesso deve ripetersi.

La parola “cron” viene dal demone crond, che legge i file di pianificazione e avvia i comandi all’istante giusto. È una soluzione molto usata per backup, pulizie periodiche, invio report, sincronizzazioni, rotazioni di file, aggiornamenti di cache e molte altre attività di manutenzione.

Quando si parla di “le stelle delle cron”, quasi sempre si intende l’uso dell’asterisco * nel crontab. Sono i caratteri che permettono di dire: “ogni minuto”, “ogni ora”, “ogni giorno”, e così via.

La struttura di una riga cron

Una riga cron standard ha questa forma:

* * * * * comando-da-eseguire

I cinque campi iniziali definiscono il momento di esecuzione. L’ordine è fisso:

1. minuto
2. ora
3. giorno del mese
4. mese
5. giorno della settimana

Dopo questi campi viene scritto il comando vero e proprio. Ecco un esempio semplice:

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

Questa riga significa: esegui backup.sh ogni giorno alle 02:30.

Come leggere i 5 campi del crontab

Ogni campo accetta numeri, simboli e combinazioni. La logica è questa:

• 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, dove spesso 0 e 7 indicano domenica

Se vuoi capire “l’inizio” e “la ripetizione”, devi pensare a ciascun campo come a un filtro. Se il valore combacia, il comando parte. Se non combacia, il comando aspetta il prossimo giro.

Per esempio:

*/5 * * * * /usr/local/bin/script.sh

Qui il simbolo */5 nel campo dei minuti significa: esegui ogni 5 minuti. Quindi ai minuti 0, 5, 10, 15, 20, 25, 30, 35, 40, 45 e 50 di ogni ora.

Il significato dell’asterisco *

L’asterisco è il simbolo più importante nel crontab. Vuol dire “qualsiasi valore valido in quel campo”.

Esempi:

• * nel campo dei minuti = ogni minuto
• * nel campo delle ore = ogni ora
• * nel campo del giorno del mese = ogni giorno del mese

Quindi:

* * * * * comando

significa: esegui il comando ogni minuto di ogni ora di ogni giorno.

È utile per test veloci, monitoraggi o attività molto frequenti. In produzione, però, va usato con attenzione: se il comando è pesante, rischi di sovraccaricare CPU, disco o database.

Come impostare l’inizio di una cron

Quando si chiede “come imposto l’inizio”, di solito si intende: da quale istante parte il primo avvio. Con cron non si indica una data di inizio separata come in alcuni scheduler moderni: si costruisce una regola che coincide con il primo momento utile.

Per esempio, se vuoi partire alle 14:00, scrivi:

0 14 * * * comando

Questo dice: esegui al minuto 0 dell’ora 14, ogni giorno.

Se vuoi che parta il primo lunedì del mese alle 09:30, puoi usare una combinazione come:

30 9 * * 1 comando

Ma attenzione: in cron classico, il campo giorno del mese e il campo giorno della settimana hanno una logica che può sorprendere. In molte implementazioni, se entrambi sono valorizzati, il comando può partire quando uno dei due campi corrisponde, non necessariamente entrambi. Per evitare ambiguità, conviene testare sempre con attenzione.

Come impostare la ripetizione

La ripetizione si definisce con i simboli e gli intervalli nei campi. I casi più comuni sono questi:

• * = ogni valore del campo
• */n = ogni n unità
• a-b = intervallo da a a b
• a,b,c = elenco di valori

Esempi pratici:

*/10 * * * * comando

Ogni 10 minuti.

0 */2 * * * comando

All’inizio di ogni ora pari, quindi ogni 2 ore.

15 8-18 * * 1-5 comando

Alle 08:15, 09:15, 10:15, fino alle 18:15, dal lunedì al venerdì.

0 6,12,18 * * * comando

Alle 06:00, 12:00 e 18:00 ogni giorno.

La ripetizione può sembrare semplice, ma l’errore tipico è confondere “ogni X minuti” con “esattamente a minuti multipli di X”.

Per esempio, */15 non significa “15 minuti dopo l’avvio del server”: significa “ai minuti divisibili per 15”, cioè 0, 15, 30, 45. Se il demone cron era fermo o il sistema era spento in quell’istante, il task non viene recuperato automaticamente, a meno di usare un altro sistema come anacron o uno scheduler più avanzato.

Esempi concreti da copiare

Ogni minuto:

* * * * * /usr/local/bin/check.sh

Ogni 5 minuti:

*/5 * * * * /usr/local/bin/check.sh

Ogni giorno alle 03:00:

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

Ogni lunedì alle 08:30:

30 8 * * 1 /usr/local/bin/report.sh

Il primo giorno del mese alle 01:00:

0 1 1 * * /usr/local/bin/fatture.sh

Dal lunedì al venerdì alle 18:00:

0 18 * * 1-5 /usr/local/bin/cleanup.sh

Ogni 30 minuti:

*/30 * * * * /usr/local/bin/sync.sh

Due volte al giorno, alle 09:00 e alle 21:00:

0 9,21 * * * /usr/local/bin/task.sh

Dove si scrivono le cron

Le pianificazioni si possono mettere in posti diversi, a seconda del sistema e del livello di controllo che vuoi avere.

• Crontab utente: con crontab -e, valido per l’utente corrente
• /etc/crontab: file di sistema, spesso con il campo utente in più
• /etc/cron.d/: directory per file di pianificazione separati
• /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/: esecuzioni periodiche predefinite

Per modificare il crontab dell’utente corrente:

crontab -e

Per vedere le regole attive:

crontab -l

Se lavori su server condivisi o in hosting, spesso è preferibile usare il crontab dell’utente applicativo, non quello di root, salvo reale necessità. Riduci il privilegio al minimo utile.

Attenzione al percorso dei comandi

Uno degli errori più comuni con cron è che il comando funziona da shell ma fallisce in cron. Il motivo di solito è il PATH diverso o un ambiente più minimale.

Per questo è meglio usare percorsi assoluti:

/usr/bin/php /var/www/html/artisan schedule:run

oppure:

/usr/local/bin/python3 /opt/script.py

Se usi comandi senza percorso completo, cron potrebbe non trovarli.

Altra buona pratica: redirigere l’output su un log, almeno in fase di test.

*/5 * * * * /usr/local/bin/script.sh >> /var/log/script.log 2>&1

Così puoi controllare eventuali errori e capire se il task parte davvero.

Come verificare che la cron stia girando

La verifica dipende dalla distribuzione, ma in genere puoi controllare il servizio cron e i log.

Su sistemi con systemd:

systemctl status cron

oppure:

systemctl status crond

Per i log, spesso trovi informazioni in:

• /var/log/syslog
• /var/log/cron

Un filtro utile può essere:

grep CRON /var/log/syslog

o:

journalctl -u cron -n 50

Se il job non parte, controlla:

• se la riga è scritta bene
• se il comando è eseguibile
• se il file ha i permessi giusti
• se l’utente ha accesso ai file e alle directory usate
• se la pianificazione è nel formato corretto

Errori tipici da evitare

Ci sono alcuni errori ricorrenti quando si impostano le cron:

• scrivere il comando senza percorso assoluto
• dimenticare di salvare il crontab dopo la modifica
• confondere il giorno del mese con il giorno della settimana
• usare un intervallo troppo aggressivo
• non gestire output ed errori
• lanciare uno script che richiede variabili d’ambiente non presenti in cron

Un caso frequente è lo script che in shell funziona, ma in cron no, perché dipende da file di configurazione caricati da bash interattiva. In questi casi conviene rendere lo script autosufficiente, oppure richiamare un wrapper che imposti bene l’ambiente.

Come ragionare su inizio e ripetizione senza sbagliare

Il modo più semplice è questo: decidi prima l’istante di partenza, poi la cadenza.

Per esempio, se vuoi un task che inizi alle 02:10 e poi si ripeta ogni ora, la regola sarà:

10 * * * * comando

Ma se vuoi che parta solo una volta al giorno alle 02:10, allora serve:

10 2 * * * comando

Se vuoi ripetere ogni 20 minuti a partire da un’ora precisa, cron classico non gestisce nativamente il concetto di “start at X then every Y” in modo assoluto come alcuni scheduler moderni. Devi tradurlo in una regola che intercetti i minuti desiderati, per esempio:

0,20,40 * * * * comando

Oppure usare uno script che controlli internamente il tempo di esecuzione.

Buone pratiche operative

Per usare bene le cron in ambiente reale, conviene seguire alcune regole semplici:

• usa percorsi assoluti per comandi e file
• logga sempre almeno in fase di test
• evita task troppo frequenti se non necessari
• impedisci esecuzioni sovrapposte se il job dura a lungo
• verifica i permessi dell’utente che esegue il task
• testa prima con una frequenza alta e temporanea, poi riduci

Per evitare sovrapposizioni, spesso si usa un lock file o strumenti come flock. Per esempio:

* * * * * /usr/bin/flock -n /tmp/script.lock /usr/local/bin/script.sh

Così il task non parte una seconda volta se la precedente esecuzione è ancora in corso.

In sintesi pratica

Le cron si impostano con 5 campi: minuto, ora, giorno del mese, mese e giorno della settimana. L’asterisco * significa “ogni valore possibile” nel campo. La ripetizione si controlla con */n, con liste, intervalli e combinazioni.

Se vuoi impostare bene inizio e ripetizione, parti sempre da tre domande:

• Quando deve partire la prima volta?
• Ogni quanto deve ripetersi?
• Come verifico che sia davvero partito?

Se rispondi bene a queste tre domande, nella maggior parte dei casi la cron viene fuori corretta al primo colpo.

Regola pratica: in cron non pensare “quando finisce”, pensa “quali istanti soddisfano questa maschera di tempo”. È questo il modo giusto di leggere gli asterischi.

Assunzione: la spiegazione è riferita al formato cron classico dei sistemi Linux/Unix più comuni.