Utilizzo del servizio di scheduling Cron: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(aggiunto paragrafo "Strumenti grafici")
 
Riga 53: Riga 53:
Le variabili a cui è possibile assegnare un valore sono:  
Le variabili a cui è possibile assegnare un valore sono:  
* <code>'''SHELL'''</code>: se non assegnata viene settata automaticamente da Cron a <code>/bin/sh</code> .<br/>Poiché in Debian l'interprete dei comandi a cui punta <code>/bin/sh</code> è <code>/bin/dash</code>, accertarsi che la sintassi dei comandi sia compatibile con '''dash'''; altrimenti modificare la variabile SHELL in maniera conforme all'interprete utilizzato, ad esempio:<pre>SHELL=/bin/bash</pre>Questa modifica potrebbe essere necessaria nel caso in cui si voglia eseguire attraverso Cron uno [[script]] Bash.
* <code>'''SHELL'''</code>: se non assegnata viene settata automaticamente da Cron a <code>/bin/sh</code> .<br/>Poiché in Debian l'interprete dei comandi a cui punta <code>/bin/sh</code> è <code>/bin/dash</code>, accertarsi che la sintassi dei comandi sia compatibile con '''dash'''; altrimenti modificare la variabile SHELL in maniera conforme all'interprete utilizzato, ad esempio:<pre>SHELL=/bin/bash</pre>Questa modifica potrebbe essere necessaria nel caso in cui si voglia eseguire attraverso Cron uno [[script]] Bash.
* <code>'''PATH'''</code>: anche questa variabile, se non le viene assegnato un valore, è settata automaticamente da Cron a <code>/usr/bin:/bin</code> . È utile cambiare questo valore se i comandi contenuti all'interno di uno script lanciato da ''Cron'' utilizzano a loro volta comandi non presenti in ''/usr/bin'' o ''/bin''oppure se si vuole inserire un comando senza specificarne il [[path]]. Per i comandi in <code>/usr/bin</code> e <code>/bin</code>, presenti cioè nel path di default, non è necessario specificarne il path completo.
* <code>'''PATH'''</code>: anche questa variabile, se non le viene assegnato un valore, è settata automaticamente da Cron a <code>/usr/bin:/bin</code> . È utile cambiare questo valore se i comandi contenuti all'interno di uno script lanciato da ''Cron'' utilizzano a loro volta comandi non presenti in ''/usr/bin'' o ''/bin'' oppure se si vuole inserire un comando senza specificarne il [[path]]. Per i comandi in <code>/usr/bin</code> e <code>/bin</code>, presenti cioè nel path di default, non è necessario specificarne il path completo.
* <code>'''LOGNAME'''</code>: contiene il login name dell'utente che esegue il comando <code>crontab</code>. Non può essere cambiata.
* <code>'''LOGNAME'''</code>: contiene il login name dell'utente che esegue il comando <code>crontab</code>. Non può essere cambiata.
* <code>'''HOME'''</code>: contiene il path della home directory associata all'utente che esegue <code>crontab</code>.
* <code>'''HOME'''</code>: contiene il path della home directory associata all'utente che esegue <code>crontab</code>.
Riga 315: Riga 315:
== Logging ==
== Logging ==


;File di log:Nel caso si abbiano problemi nel far funzionare correttamente il servizio di scheduling, si può in qualsiasi momento  dare un'occhiata al file di log <code>/var/log/syslog</code>  in cui il demone Cron invia i propri messaggi di sistema.<br/>Alternativamente si può fare in modo da avere un file di log separato per contenere i messaggi di Cron.<br/>Basta decommentare la riga del file <code>/etc/rsyslog.conf</code> :<pre>cron.*                          /var/log/cron.log</pre>e riavviare "rsyslog":<pre># service rsyslog restart</pre>per avere tutti i messaggi in <code>/var/log/cron.log</code> .
;File di log:Nel caso si abbiano problemi nel far funzionare correttamente il servizio di scheduling, si può in qualsiasi momento  dare un'occhiata al file di log <code>/var/log/syslog</code>  in cui il demone Cron invia i propri messaggi di sistema.<br/>Alternativamente è possibile avere un file di log separato per contenere i messaggi di Cron.<br/>Basta decommentare la riga del file <code>/etc/rsyslog.conf</code> :<pre>cron.*                          /var/log/cron.log</pre>e riavviare "rsyslog":<pre># service rsyslog restart</pre>per avere tutti i messaggi in <code>/var/log/cron.log</code> .




;Log level:Il livello di logging (cioè le informazioni che vengono scritte nei log prodotti da ''Cron'') può essere impostato nel file <code>/etc/default/cron</code> agendo sulla direttiva "EXTRA_OPTS". Ad esempio:<pre>EXTRA_OPTS="-L 8"</pre>I valori possibili sono:<pre>0    nessun log a meno che non avvenga un errore &#10;1    avvio del cronjob &#10;2    fine del cronjob &#10;4    log del cronjob con stato d'uscita diverso da 0 &#10;8    log anche dei processi-figlio del processo eseguito da Cron &#10;</pre>I valori possono essere sommati se si vuol loggare più di un evento.<br/>Con:<pre>EXTRA_OPTS="-L 15"</pre>si ottiene la massima "verbosità" del log.<br/>Per rendere effettive queste modifiche, servirà riavviare ''Cron'':<pre># service cron restart</pre>
;Log level:Il livello di logging (cioè le informazioni che vengono scritte nei log prodotti da ''Cron'') può essere impostato nel file <code>/etc/default/cron</code> agendo sulla direttiva "EXTRA_OPTS". Ad esempio:<pre>EXTRA_OPTS="-L 8"</pre>I valori possibili sono:<pre>0    nessun log a meno che non avvenga un errore &#10;1    avvio del cronjob &#10;2    fine del cronjob &#10;4    log del cronjob con stato d'uscita diverso da 0 &#10;8    log anche dei processi-figlio del processo eseguito da Cron &#10;</pre>I valori possono essere sommati se si vuol loggare più di un evento.<br/>Con:<pre>EXTRA_OPTS="-L 15"</pre>si ottiene la massima "verbosità" del log.<br/>Per rendere effettive queste modifiche, servirà riavviare ''Cron'':<pre># service cron restart</pre>
== Strumenti grafici ==
Benché il comando <code>crontab</code> sia assoultamente sufficiente per gestire i lavori da assegnare a Cron, a volte può essere comodo avere a disposizione un'interfaccia grafica anziché utilizzare la riga di comado soprattutto quando si utilizza Cron per la prima volta.<br/>
{{Warningbox | Fare un backup del propri cronjob. Questi strumenti sovrascrivono i file corrispondenti in <code>/var/spool/cron/crontabs</code> e quindi le informazioni qui contenute (ad esempio i commenti) potrebbero andare perse.}}
{| class="wikitable"
!Pacchetto
!Ambiente grafico
!Note
|-
|kde-config-cron || KDE || crea una voce in "Avvio e Spegnimento" all'interno delle impostazioni di KDE
|}


== Problemi comuni ==
== Problemi comuni ==

Versione attuale delle 14:58, 9 apr 2021

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione al servizio di scheduling Cron

Alcuni processi devono essere eseguiti a determinati orari, un determinato numero di volte. Esempi possono essere i processi di backup che vengono lanciati ogni notte, oppure un analizzatore di log che deve girare ogni minuto.
Questi processi devono girare un certo numero di volte oppure in determinati giorni; il resto del tempo essi stanno fermi fino a quando un utente non interagisce con essi e li richiama (con gli appositi comandi). Questi sono i casi in cui il demone CRON si rende utile. Vi permette di programmare (o "schedulare", come si dice in gergo) l'esecuzione di un lavoro ("job" o "cronjob") in qualsiasi momento desideriate, ogni minuto, ogni ora, giornalmente, settimanalmente, mensilmente, annualmente.

Le basi

Cron viene lanciato in background all'avvio del sistema sicché non c'è bisogno di lanciarlo manualmente. All'avvio Cron legge il file /etc/crontab per le voci (le cosiddette "entry") di sistema, i file contenuti nella directory /etc/cron.d/ e i file in /var/spool/cron/crontabs per le voci relative agli utenti che si trovano nel file /etc/passwd. Tutti i job di ciascuna voce (crontab) sono caricati nella memoria del demone Cron.

Ciascun utente, compreso root, ha il proprio file crontab nella directory /var/spool/cron/crontabs/; ogni crontab può contenere uno o più cronjobs.

Il demone Cron esegue diversi compiti:

  • Controlla eventuali cambiamenti nei file contenuti in /etc/cron.d/ o nel file/etc/crontab. In questo caso aggiorna il modtime (vale a dire la data e l'ora dell'ultima modifica) per questi crontab e li ricarica nella sua memoria interna;
  • Monitora il comando crontab che si occupa, per ciascun utente, di modificare i lavori di Cron contenuti in /var/spool/cron/crontabs. Le modifiche effettuate con il comando crontab comportano, da parte di Cron, l'aggiornamento dei crontab in memoria e del loro modtime;
  • Confronta l'ora/data dei job contenuti in memoria (modtime) con l'ora/data corrente per stabilire se il comando schedulato debba essere avviato oppure no;

In base a questo modo di operare, non è necessario far ripartire Cron ogni volta che vengono effettuati dei cambiamenti tramite il comando crontab.

Utilizzare il comando crontab

Il demone Cron legge i file contenuti in /var/spool/cron/crontabs/ relativi ai cronjobs che ogni specifico utente vuole eseguire. È importante sapere che questi file non vanno modificati direttamente, ma solo attraverso il comando crontab seguito dagli appropriati flag che specificano se lanciare crontab per avere la lista o per aggiungere, rimuovere e modificare compiti.

La sintassi per il programma crontab è la seguente: 

crontab [-u user] file

crontab [-u user] -l -e -r

I parametri significano:

  • -u : questa opzione comunica al sistema il nome dell'utente che "possiede" il file. Se l'opzione -u è omessa, il sistema deduce per default che si sta operando sul crontab dell'utente che lancia il comando. NOTA: Il comando switch user (su) può confondere il crontab, così se siete nello switch su assicuratevi di utilizzare l'opzione -u.
  • -l : questa opzione dice a crontab di elencare i file nello standard output, cioè di visualizzare il file.
  • -e : questa opzione dice a crontab di editare il file. Cron usa l'editor definito dalle variabili EDITOR o VISUAL. Se nessuna di queste due variabili è definita, parte in automatico l'editor di default. L'editor salva il file in /tmp; quando si esce dall'editor, il file è immediatamente salvato in /var/spool/cron/crontabs e viene aggiornato il campo data/ora. Questo è il comando principale da utilizzare se si vuole modificare il proprio file crontab per cancellare o inserirvi i lavori da assegnare a Cron.
  • -r : questa opzione rimuove il file crontab. Se nessun utente viene specificato attraverso l'opzione '-u', rimuove il file crontab dell'utente che lancia il comando.
  • file : inserisce il contenuto del file nel crontab dell'utente specificato tramite l'opzione '-u'. Se non viene specificato nessun utente, allora il contenuto del file sarà inserito nel crontab dell'utente che lancia il comando (vedi anche: Importare un file crontab)

cron.allow & cron.deny

In un sistema Debian, di default, tutti gli utenti, oltre root, possono eseguire il comando crontab.
Questo comportamento può essere modificato attraverso la creazione di due file:

/etc/cron.allow
se questo file esiste, allora solo gli utenti qui specificati sono abilitati all'utilizzo di crontab. Su ogni riga del file va specificato un solo utente.
/etc/cron.deny
se questo file esiste, allora gli utenti qui specificati non potranno utilizzare crontab. Anche per questo file su ogni riga va specificato un solo utente.

Se entrambi i file sono presenti, verrà preso in considerazione solo il file /etc/cron.allow.
Root è sempre abilitato all'utilizzo di crontab, indipendentemente dall'esistenza o meno di questi due file e dal loro contenuto.

Voci in un file crontab

Solo due tipi di voci sono permesse in un file crontab: i settaggi ambientali (Crontab Environmental settings) e i settaggi di comando (Crontab Command settings).

Crontab Environmental settings

I settaggi ambientali utilizzano la seguente forma: 

NOME = valore

che, per motivi di leggibilità, dovrebbero essere inseriti in testa al file generato dal comando crontab.
Le variabili a cui è possibile assegnare un valore sono:

  • SHELL: se non assegnata viene settata automaticamente da Cron a /bin/sh .
    Poiché in Debian l'interprete dei comandi a cui punta /bin/sh è /bin/dash, accertarsi che la sintassi dei comandi sia compatibile con dash; altrimenti modificare la variabile SHELL in maniera conforme all'interprete utilizzato, ad esempio:
    SHELL=/bin/bash
    Questa modifica potrebbe essere necessaria nel caso in cui si voglia eseguire attraverso Cron uno script Bash.
  • PATH: anche questa variabile, se non le viene assegnato un valore, è settata automaticamente da Cron a /usr/bin:/bin . È utile cambiare questo valore se i comandi contenuti all'interno di uno script lanciato da Cron utilizzano a loro volta comandi non presenti in /usr/bin o /bin oppure se si vuole inserire un comando senza specificarne il path. Per i comandi in /usr/bin e /bin, presenti cioè nel path di default, non è necessario specificarne il path completo.
  • LOGNAME: contiene il login name dell'utente che esegue il comando crontab. Non può essere cambiata.
  • HOME: contiene il path della home directory associata all'utente che esegue crontab.
  • MAILTO: di default Cron invia un'email con l'output dei comandi presenti nel crontab all'utente che ne è proprietario.
  1. se questa variabile è settata, il demone Cron invierà un'email, con l'output del/dei comando/comandi specificati in crontab, all'utente specificato. È possibile specificare più utenti separandoli con una virgola;
  2. se la variabile è settata a "", allora non verranno inviate email;
  3. se la variabile non è specificata, verrà inviata un'email all'utente a cui appartiene il crontab.
    La seguente riga mostra la variabile MAILTO settata ad uno specifico utente (luca):
    # spedisce tutti gli output all'utente *luca*
MAILTO=luca
    mentre la successiva riga informa Cron di non inviare email:
    # non viene inviata nessuna email 
MAILTO=""
    ovviamente, affinché Cron possa inviare con successo le email, bisogna avere un MTA installato e funzionante sulla propria macchina.

Crontab Command settings

I settaggi di comando usano un formato standard: ogni riga è composta da cinque campi ora/data seguiti da un campo contenente il comando da eseguire.
Per il crontab di sistema (/etc/crontab) e per i lavori di Cron presenti in /etc/cron.d/, vi è un settimo campo, compreso tra i primi cinque e il comando da eseguire, che contiene lo username dell'utente con i cui permessi verrà lanciato il comando.
Vedremo in seguito che sono possibili alcune eccezioni a questa regola.

I campi disponibili per la data e l'ora sono i seguenti: 

Campi | Valori ammessi
----------------
minuti | 0-59
ore | 0-23
giorno | 1-31
mese | 1-12
giorno della settimana | 0-7 (0 & 7 indicano la domenica)

Ecco lo schema per una generica linea presente in un file crontab: 

.---------------- [m]inute: minuto (0 - 59) 
|  .------------- [h]our: ora (0 - 23)
|  |  .---------- [d]ay [o]f [m]onth: giorno del mese (1 - 31)
|  |  |  .------- [mon]th: mese (1 - 12) OPPURE jan,feb,mar,apr... 
|  |  |  |  .---- [d]ay [o]f [w]eek: giorno della settimana (0 - 7) (la domenica vale 0 o 7)  OPPURE sun,mon,tue,wed,thu,fri,sat 
|  |  |  |  |

*  *  *  *  *  comando da eseguire

Sintassi

Ogni file crontab specifica su ogni riga un compito da assegnare al demone Cron.
Una riga può contenere dei commenti (la riga inizia con il carattere "#") ed essere posizionata in qualunque punto del file. Non è possibile inserire un commento alla fine di una riga che già contiene un comando.
Le righe contenenti i command settings sono costituite da campi separati da spazi o caratteri di tabulazione.
I primi cinque campi possono contenere un numero, un intervallo di valori, stringhe particolari o un asterisco (*). Quest'ultimo sta a indicare ogni possibile valore ammesso dell'intervallo; quindi un asterisco nel terzo campo indica che il comando verrà eseguito ogni giorno.
Se tutti i primi cinque campi contengono un asterisco, il comando verrà eseguito ogni minuto.
Questo è un semplice esempio di crontab editabile attraverso il comando crontab -e : 

00 3 1 7 * /comando/da/eseguire

tenendo conto di quest'esempio, il comando verrà eseguito:

Campo 1
quando i minuti sono 0.
Campo 2
quando l'ora vale 3.
Campo 3
quando il giorno del mese vale 1.
Campo 4
quando il mese è il settimo dell'anno ossia luglio.
Campo 5
ogni giorno della settimana. Poiché è specificato il giorno del mese, questo campo viene ignorato (vale anche il caso opposto; più avanti sarà spiegato in che modo Cron interpreta le righe di un file crontab in cui sono specificati sia il giorno del mese che quello della settimana).

Quindi, in breve, il comando è eseguito il primo luglio alle ore 3,00.

Naturalmente è possibile specificare intervalli di tempo, intervalli di date o combinazioni di questi:

  • Esempio 1
1-30 * * * * /comando/da/eseguire

il comando verrà eseguito ogni giorno, ogni ora e quando i minuti vanno da 1 a 30.

  • Esempio 2
*/10 * * * * /comando/da/eseguire

il comando verrà eseguito ogni 10 minuti, quando i minuti sono 00, 10, 20, 30, 40 e 50.

  • Esempio 3
30 * 1-7 * * /comando/da/eseguire

il comando verrà eseguito i primi sette giorni di ogni mese, ad ogni ora e quando i minuti valgono 30.

  • Esempio 4
00 */2 15 * * /comando/da/eseguire

il comando verrà eseguito il quindicesimo giorno di ogni mese, ogni due ore.

  • Esempio 5
00 1-9/2 1 5 * /comando/da/eseguire

il comando viene eseguito il primo maggio alle 1,00 - 3,00 - 5,00 - 7,00 - 9,00. Cioè ogni due ore dalle 1,00 alle 9,00.

  • Esempio 6
00 1-10/2 1 5 * /comando/da/eseguire

il comando viene eseguito il primo maggio alle 1,00 - 3,00 - 5,00 - 7,00 - 9,00. Cioè ogni due ore dalle 1,00 alle 10,00. Si noti come l'ultimo valore utile dell'intervallo non coincida, in questo caso, con l'ora in cui viene fatta partire l'ultima esecuzione giornaliera del comando.

  • Esempio 7
00 13 2,8,14 * * /comando/da/eseguire

il comando verrà eseguito il secondo, l'ottavo e il quattordicesimo giorno di ogni mese alle 13.00

  • Esempio 8
30 13 1-15 4,10 * /comando/da/eseguire

il comando verrà eseguito i primi quindici giorni di aprile e ottobre alle 13,30.

  • Esempio 9
*/30 13,20 * 1-7,9-12 1-5 /comando/da/eseguire

il comando verrà eseguito nei giorni feriali (da lunedì a venerdì) di tutti i mesi tranne agosto, alle 13,00 - 13,30 - 20,00 - 20,30.

  • Esempio 10
00 14,19 1-15 * 5 /comando/da/eseguire

il comando verrà eseguito alle 14,00 e alle 19,00 dei primi quindici giorni di ogni mese e anche ogni venerdì.
Attenzione.
Poiché i giorni possono essere specificati sia nel terzo che nel quinto campo e nel caso in cui questi due campi abbiano entrambi un valore diverso dall'asterisco, il demone Cron lancia il comando quando i campi corrispondono alla data corrente e in maniera indipendente l'uno dall'altro. In questo caso, dunque, verrà eseguito il comando sia negli specificati giorni del mese sia nei giorni specificati della settimana.
Quindi l'esempio precedente non porta al risultato di lanciare il comando solo nei primi quindici giorni di ogni mese quando il giorno è venerdì, ma al risultato di lanciare il comando nei primi quindici giorni di ciascun mese e anche ogni venerdì di ogni settimana dell'anno.

Se si vuole ottenere il risultato di lanciare un comando in un particolare giorno della settimana solo se questo coincide con un giorno del mese o se appartiene a un intervallo di giorni del mese, bisogna eseguire un test separato sulla data. Il test può essere fatto sia all'interno di crontab, sia all'interno di uno script lanciato da crontab.

  • Esempio 10

Questo è un esempio che mostra come eseguire un comando solo alla mezzanotte della prima domenica di ogni mese: 

00 00 1-7 * * [ $(/bin/date '+\%u') -eq 7 ] && /comando/da/eseguire
  • Esempio 11

Quest'altro esempio mostra come eseguire un comando alle 20,00 nei giorni che vanno dal 5 al 10 di ogni mese e solo se questi giorni corrispondono a martedì o venerdì: 

00 20 5-10 * * [ $(/bin/date '+\%u') -eq 2 -o $(/bin/date '+\%u') -eq 5 ] && /comando/da/eseguire

notare in entrambi i casi l'uso dell'escape del carattere '%'.
Consultare le manpages dei comandi date e test per ottenere informazioni sul loro funzionamento.

Stringhe speciali

Al posto dei primi cinque campi è possibile inserire particolari stringhe che il demone Cron interpreta come valori corretti per i campi data/ora. Vediamole: 

   stringa        significato
   ------         -------
   @reboot        Lancia il comando all'avvio del sistema
   @yearly        Lancia il comando una volta all'anno. Uguale a "0 0 1 1 *"
   @annually      (come @yearly)
   @monthly       Lancia il comando una volta al mese. Uguale a "0 0 1 * *"
   @weekly        Lancia il comando una volta alla settimana. Uguale a "0 0 * * 0"
   @daily         Lancia il comando una volta al giorno. Uguale a "0 0 * * *"
   @midnight      (come @daily)
   @hourly        Lancia il comando una volta all'ora. Uguale a "0 * * * *"

in base a questa tabella sono perfettamente ammissibili le seguenti righe per il file crontab: 

@daily /comando/da/eseguire

con cui il comando verrà eseguito una volta al giorno; in particolare a mezzanotte di ogni giorno. 

@monthly /comando/da/eseguire

con cui il comando verrà eseguito ogni mese; in particolare il primo giorno di ogni mese, a mezzanotte.

Messaggi di output

L'esecuzione di comandi o script può comportare l'invio allo standard output o allo standard error dei loro messaggi d'esecuzione.
Normalmente tali messaggi vengono inviati allo schermo ma, nel caso vengano eseguiti tramite Cron, l'output sarà reindirizzato attraverso l'MTA di sistema all'utente specificato tramite la variabile MAILTO.
Questo può portare all'invio di messaggi con output indesiderato, o perché totalmente non richiesto per un determinato cronjob o perché si desidera soltanto la notifica dei messaggi d'errore nel caso il comando abbia avuto problemi.
Per operare su questo aspetto si può reindirizzare l'output del comando specificato in Cron come si farebbe normalmente per la shell.

  • Notifica solo dei messaggi d'errore. Si reindirizza lo standard output verso "/dev/null", ad esempio:
00 3 1 7 * /comando/da/eseguire > /dev/null
  • Soppressione totale dei messaggi. Si reindirizza sia lo standard output che lo standard error verso "/dev/null", ad esempio:
00 3 1 7 * /comando/da/eseguire > /dev/null 2>&1
Si noti che, in questo caso, l'impostazione:
MAILTO = ""
avrebbe effetto su tutti i cronjob e non solo su quello voluto.
  • Utilizzo di un file di log personale
00 3 1 7 * /comando/da/eseguire >> /percorso/desiderato/mio_file.log 2>&1

Esempio di crontab

Di seguito un esempio di file crontab in cui sono specificate le variabili d'ambiente e i settaggi di comando: 

# Crontab Environmental settings
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# Crontab Command settings

# m h dom m dow command
00 3 * 7 0 /comando/da/eseguire
15 20 * 1-7 * /comando/da/eseguire2
*/30 7,21 1-15 1 * /comando/da/eseguire3
@reboot /comando/da/eseguire4

Crontab di sistema: /etc/crontab

Anche la nostra macchina ha il proprio file crontab in cui sono specificati i comandi di sistema da lanciare ad intervalli regolari. Il file è contenuto in /etc/crontab e le sue modifiche sono automaticamente intercettate da Cron.
In questo file è utilizzato un campo aggiuntivo, dopo i primi cinque campi data/ora e prima del comando, che specifica l'utente con i cui permessi verrà eseguito il comando.

Guardiamo i settaggi di comando al suo interno: 

# m h dom mon dow user  command
21 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Sono presenti quattro righe relative ad altrettanti compiti per Cron. Se sul nostro sistema non è installato anacron, il demone Cron eseguirà il comando run-parts che ha il compito di lanciare tutti gli script presenti nelle cartelle /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly .

Prima riga

il comando run-parts lancia gli script presenti in /etc/cron.hourly ogni ora e quando i minuti valgono 21

Seconda riga

il comando run-parts lancia gli script presenti in /etc/cron.daily alle 6,25 di ogni giorno.

Terza riga

il comando run-parts lancia gli script presenti in /etc/cron.weekly ogni domenica alle 6,47.

Quarta riga

il comando run-parts lancia gli script presenti in /etc/cron.monthly il primo di ogni mese alle 6,52

In breve, il crontab di sistema indica a Cron di lanciare ad intervalli regolari gli script di sistema contenuti nelle cartelle sopra indicate.
Tipicamente questo file non necessita di essere editato, a meno che non ci si accorga che gli script non possono essere lanciati a causa dell'inattività della macchina alla data/ora specificata. Come si può ben notare, il comando run-parts viene lanciato con i permessi di root (sesto campo).

È importante sottolineare che, di default, nel file /etc/crontab è indicata un'ora durante la quale è molto probabile che una macchina desktop sia spenta e che, quindi, Cron sia impossibilitato ad eseguire gli script presenti nelle directory /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly .
Poiché in queste directory sono contenuti script che necessitano di essere eseguiti in quanto permettono, tra le altre cose, la rotazione dei log e il backup di file importanti di sistema, è vivamente consigliato editare il file modificando le ore/minuti del cronjob in modo da essere sicuri che il sistema sia attivo all'ora specificata.
Ad esempio: 

# m h dom mon dow user  command
21 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 8    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 8    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 8    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Se non si vuole editare il file /etc/crontab si può, più semplicemente, installare anacron.
Ovviamente per un server sempre acceso, e con Cron attivo e funzionante, non c'è bisogno di alcuna modifica né di installare anacron.

Le directory /etc/cron.*/

Per completezza d'informazione si tratterà brevemente delle directory viste nel paragrafo precedente in cui sono contenuti gli script di sistema, o forniti da applicazioni, che necessitano di essere eseguiti ad intervalli regolari.

  • /etc/cron.hourly: in questa directory sono contenuti gli script da eseguire ogni ora;
  • /etc/cron.daily: in questa directory sono contenuti gli script da eseguire ogni giorno;
  • /etc/cron.weekly: in questa directory sono contenuti gli script da eseguire ogni settimana;
  • /etc/cron.monthly: in questa directory sono contenuti gli script da eseguire ogni mese;

La data/ora in cui vengono eseguiti gli script contenuti in queste directory è quella specificata nel file /etc/crontab.

  • /etc/cron.d/: in questa directory sono vi sono script ma file nel formato di crontab. Qui il sistema specifica i lavori da passare a Cron per intervalli temporali diversi dall'ora o dal giorno o dal mese o dalla settimana.
    Le righe presenti nei file contenuti in quest'ultima directory devono seguire il seguente schema:
    * * * * * utente comando
    Le modifiche ai file di questa directory vengono automaticamente intercettate da Cron e, come per il file /etc/crontab, anche per i file contenuti in questa directory viene specificato l'utente con i cui permessi deve essere eseguito il comando.
    Anacron non esegue i cronjob contenuti in questa directory.

Tutte queste cinque directory, per una questione di pulizia del sistema, non dovrebbero essere utilizzate per inserirvi script da parte degli utenti, anche se nulla vieta di farlo. Le controindicazioni sono quelle di "dimenticarsi" qualche script o di lanciare, coi permessi di root, qualche comando che necessiterebbe solo dei semplici permessi utente.
Se non si hanno esigenze particolari, la strada per assegnare dei lavori a Cron è sempre quella di avvalersi del comando: 

 crontab -e

sia per root che per un normale utente.

Esportare un file crontab

Se si vuole salvare il proprio crontab per esportarlo su un'altra macchina o semplicemente per farne una copia di backup, la procedura è semplicissima: 

$ crontab -l > mycrontab

in questo modo il file crontab verrà salvato nel file mycrontab.
Per salvare il crontab di root è sufficiente lanciare lo stesso comando con i permessi di root.
Se si vuole salvare il crontab di un altro utente, eseguire con i permessi di root: 

# crontab -u utente -l > usercrontab

I nomi scelti per i file sono puramente indicativi.

Importare un file crontab

Questa procedura è utile per importare un file in cui si è precedentemente salvato il contenuto di un file crontab oppure per importare un file editato a mano attraverso un qualsiasi altro editor, testuale o grafico: 

$ crontab mycrontab

in questo modo il contenuto di mycrontab verrà inserito nel crontab dell'utente che lancia il comando.
Per un diverso utente, eseguire da root: 

# crontab -u utente usercrontab

Anche in questo caso i nomi dei file sono puramente indicativi.
Attenzione: il file crontab, se presente, verrà sovrascritto!

Logging

File di log
Nel caso si abbiano problemi nel far funzionare correttamente il servizio di scheduling, si può in qualsiasi momento dare un'occhiata al file di log /var/log/syslog in cui il demone Cron invia i propri messaggi di sistema.
Alternativamente è possibile avere un file di log separato per contenere i messaggi di Cron.
Basta decommentare la riga del file /etc/rsyslog.conf :
cron.*                          /var/log/cron.log
e riavviare "rsyslog":
# service rsyslog restart
per avere tutti i messaggi in /var/log/cron.log .


Log level
Il livello di logging (cioè le informazioni che vengono scritte nei log prodotti da Cron) può essere impostato nel file /etc/default/cron agendo sulla direttiva "EXTRA_OPTS". Ad esempio:
EXTRA_OPTS="-L 8"
I valori possibili sono:
0    nessun log a meno che non avvenga un errore 
1    avvio del cronjob 
2    fine del cronjob 
4    log del cronjob con stato d'uscita diverso da 0 
8    log anche dei processi-figlio del processo eseguito da Cron
I valori possono essere sommati se si vuol loggare più di un evento.
Con:
EXTRA_OPTS="-L 15"
si ottiene la massima "verbosità" del log.
Per rendere effettive queste modifiche, servirà riavviare Cron:
# service cron restart

Strumenti grafici

Benché il comando crontab sia assoultamente sufficiente per gestire i lavori da assegnare a Cron, a volte può essere comodo avere a disposizione un'interfaccia grafica anziché utilizzare la riga di comado soprattutto quando si utilizza Cron per la prima volta.

Warning.png ATTENZIONE
Fare un backup del propri cronjob. Questi strumenti sovrascrivono i file corrispondenti in /var/spool/cron/crontabs e quindi le informazioni qui contenute (ad esempio i commenti) potrebbero andare perse.


Pacchetto Ambiente grafico Note
kde-config-cron KDE crea una voce in "Avvio e Spegnimento" all'interno delle impostazioni di KDE

Problemi comuni

Lo script viene eseguito normalmente ma non attraverso Cron
Il problema può essere in larga parte dovuto a due fattori: lo script fa uso di una sintassi diversa da quella usata da dash (leggere a tal proposito il paragrafo relativo ai "Crontab Environmental settings" e, in particolare, l'uso della variabile SHELL) oppure lo script esegue comandi che non ricadono all'interno dei percorsi definiti dalla variabile PATH. In quest'ultimo caso si può far ricorso al comando "strace" (presente nel pacchetto omonimo):
$ strace -f -e trace=execve ./nomescript
che mostrerà il percorso dei comandi eseguiti dallo script. Modificare, se necessario, la variabile PATH affinché preveda percorsi diversi da /usr/bin o /bin .

Note

Il sistema non va indietro nel tempo a raccogliere i lavori di Cron, ma li esegue solo se la data e l'ora sono uguali alla voce nel file. Se il computer è spento quando dovrebbe essere eseguito un comando in Cron ed anacron non è installato, quel comando non viene eseguito.



Guida scritta da: Ferdybassi Swirl-auth100.png Guida Debianized
Estesa da:
S3v
Verificata da:
S3v
Ferdybassi (dopo l'estensione)
Stemby
HAL 9000 19:40, 31 mar 2015 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Utilizzo_del_servizio_di_scheduling_Cron&oldid=44368"