Orale Parte 2 Ambienti di Programmazione

3.2 I servizi di base

In questa sezione prenderemo in esame la configurazione di alcuni servizi di base, presenti fin

dalle origini in tutti i sistemi unix-like, come quelli per l’esecuzione periodica o differita dei

comandi, e quelli per la gestione della registrazione dei messaggi di servizio. Seguendo la filosofia

fondamentale di Unix tutti questi servizi sono realizzati tramite degli appositi programmi, detti

demoni (si ricordi quanto detto in sez. 2.1.2), che lavorano in background anche quando nessuno

è collegato al sistema ed il cui comportamento viene controllato attraverso i rispettivi file di

configurazione.

3.2.1 Il servizio cron

Una funzionalità importante presente in qualunque sistema operativo è quella dell’esecuzione di

programmi su base periodica, essenziale per compiere tutte quelle operazioni che devono essere

eseguite ad un tempo fissato. Abbiamo già incontrato due operazioni che vengono gestite in

questo modo, come la creazione del database dei file di e l’indicizzazione delle pagine di

locate

manuale, trattate rispettivamente in sez. 2.2.2 e 2.4.2.

9 su Debian è ancora presente il vecchio comando , ma questo è deprecato in favore della riconfigu-

tzconfig

timezone

razione del pacchetto dei dati delle con (vedi sez. 4.2.3) , su RedHat occorre invece

dpkg-reconfigure tzdata

usare il comando dedicato .

system-config-date

3. La configurazione dei servizi 179

La gestione dell’esecuzione periodica di programmi per compiere operazioni nel sistema viene

realizzata dal servizio chiamato che è stato implementato attraverso l’uso dell’omonimo

cron,

demone . Il demone ha il compito di svegliarsi ogni minuto ed eseguire ogni programma che

cron

è stato programmato per quel momento.

Il file di configurazione principale di è che contiene l’elenco delle operazioni

cron /etc/crontab

periodiche generali da eseguire nel sistema. Il primo file controllato da per decidere se c’è

cron

da eseguire una operazione è questo. In genere si deve intervenire su questo file solo quando si

vuole cambiare uno degli orari a cui le operazioni prestabilite vengono eseguite o per inserire una

nuova operazione periodica. Oltre a il programma controlla anche il contenuto della

/etc/crontab

directory dove i vari pacchetti possono inserire i loro file per esigenze specifiche,

/etc/cron.d/

per i quali vale la stessa sintassi di .

/etc/crontab

Il formato del file segue la solita regola di ignorare righe vuote ed inizianti per “ ”. Ogni riga

#

deve contenere o una assegnazione di una variabile di ambiente o la specificazione di una azione

periodica. L’azione viene specificata da una serie di campi separati da spazi o tabulatori, i primi

cinque indicano la periodicità con cui il comando indicato nell’ultimo campo viene eseguito, il

sesto campo indica l’utente per conto del quale eseguire il comando scritto nel seguito della riga.

I cinque campi della periodicità indicano rispettivamente: minuto (da 0 a 59), ora (da 0 a

23), giorno del mese (da 1 a 31), mese dell’anno (da 1 a 12) e giorno della settimana (da 0 a

7, dove sia 0 che 7 indicano la domenica). Per quest’ultimo campo sono accettati anche valori

tipo Mon, Thu, etc. L’utilizzo del carattere “ ” vale da jolly e lo si usa per indicare un valore

*

qualsiasi. Se il tempo corrente corrisponde a tutti i valori specificati nei cinque campi il comando

viene eseguito.

Il demone di GNU/Linux supporta poi alcune estensioni non presenti in altri sistemi

cron

10

unix-like. Si può usare una lista (separata da virgole) per indicare più valori, un intervallo,

specificando gli estremi separati con un “ ”. Infine il programma supporta la possibilità di

-

specificare periodi personalizzati attraverso l’uso del carattere jolly abbinato con il carattere “ ”

/

seguito dal divisore da applicare al valore generico del campo; cos`ı ad esempio usando nel

*/2

primo campo si intenderà chiedere la ripetizione del lavoro ogni due minuti. Per la descrizione

del formato del file completa di tutti i dettagli, si faccia riferimento alla pagina di manuale del

file, accessibile con .

man 5 crontab

Si tenga presente che siccome il programma specificato nella parte conclusiva della linea viene

eseguito direttamente dal demone , non saranno necessariamente definite le usuali variabili

cron

di ambiente presenti normalmente quando si esegue una shell. In particolare è da tenere presente

che il demone si limita a definire solo alcune di esse ed in particolare per quanto riguarda PATH

questa comprenderà soltanto le directory e . Altre variabili definite da sono

/usr/bin /bin cron

e , che corrisponderanno al nome utente e alla directory personale dell’utente per

LOGNAME HOME

conto del quale viene eseguito il programma.

Per questo motivo se un programma necessita della presenza di valori diversi da quelli di

default o di altre variabili, occorrerà inserire in testa al file le relative definizioni. Queste de-

finizioni seguono la stessa sintassi che si usa nella shell, con la differenza che non esegue

cron

la per cui non si potrà fare riferimento ad altre variabili all’interno di una

variable expansion,

definizione.

10 creato da Paul Vixie, noto anche per essere l’autore di

vixie-cron, BIND,

si tratta del programma il server

DNS (vedi sez. 9) più usato al mondo.

3. La configurazione dei servizi 179

Infine un ruolo particolare viene giocato dalla variabile , che indica l’utente a cui inviare

MAILTO

per posta elettronica l’eventuale output del programma posto in esecuzione. Infatti quando cron

esegue il comando questo non è collegato a nessun terminale, e si pone pertanto il problema di

come gestire gli eventuali dati in uscita. La soluzione scelta è stata appunto quella di inviarli

per posta elettronica all’utente per conto del quale è stato eseguito il comando, questo a meno

che non si sia definita la variabile per indicare un altro destinatario, se la variabile è

MAILTO

definita, ma vuota, l’invio verrà disabilitato. Questo è il motivo per cui spesso nei comandi

lanciati tramite viene eseguita una redirezione dello su in modo

standard output

cron /dev/null

da scartare eventuali dati in uscita.

Un esempio del contenuto del file , preso dalla versione installata di default su

/etc/crontab

una Debian Squeeze, è il seguente: /etc/crontab

# Unlike any other crontab you don’t have to run the ‘crontab’

# command to install the new version when you edit this file

# and files in /etc/cron.d. These files also have username fields,

# that none of the other crontabs do.

SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user command

17 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 )

* *

#

in cui vengono definite le variabili che indicano quale shell usare ed il path dei comandi e vengono

impostate una serie di operazioni. In questo caso ad esempio la seconda riga si legge come minuto

25, ore 6, essendo le altre indicazioni tutti si intende che giorno del mese, mese e giorno della

*

settimana sono qualsiasi, allo stesso modo si interpretano le altre righe.

Con il contenuto mostrato nell’esempio ci saranno allora delle azioni che vengono eseguite

ogni ora al minuto 17, tutti i giorni alle ore 6:25, tutte le domeniche alle 6:47 e tutti i primi

giorni del mese alle 6:52, che vanno a costituire le operazioni orarie, giornaliere, settimanali e

mensili da eseguire in maniera automatica. Queste azioni sono eseguite attraverso il comando

il cui scopo è effettuare l’esecuzione, in ordine alfabetico, degli script presenti nella

run-parts

directory passata come argomento.

Nel caso gli script sono quelli delle directory elencate nell’esempio, per cui se non si hanno

esigenze particolari non è il caso di intervenire su questo file ma di aggiungere il proprio script

direttamente in , , . Occorre comunque

/etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

fare attenzione, perché non esegue gli script il cui nome contiene caratteri diversi da

run-parts

lettere maiuscole e minuscole, numeri, il carattere di sottolineatura ed il “ ” (per i dettagli sul

-

funzionamento del comando si consulti la relativa pagina di manuale).

Si noti comunque come nel file di mostrato nell’esempio viene fatto un controllo

crontab

preventivo della presenza del comando . Questo è un sostituto di utilizzato origina-

anacron cron

riamente sulle macchine che non è previsto siano sempre accese, come le stazioni di lavoro, che

3. La configurazione dei servizi 181

si incarica di eseguire le operazioni periodiche tenendo conto anche del fatto che queste possono

non essere state effettuate in precedenza perché la macchina era spenta.

In Debian se questo programma viene installato è quello a cui viene delegato il compito

anche di eseguire le operazioni giornaliere, settimanali e mensili illustrate in precedenza e non

è necessario l’intervento di . L’installazione di default non prevede la presenza di questo

cron

programma, per cui il comando non sarà presente e verrà eseguito invece .

run-parts

Altre distribuzioni come RedHat installano invece di default questo programma e delegano

direttamente ad esso l’esecuzione delle operazioni periodiche. Queste sono controllate dal file

che prevede di nuovo la possibilità di definire delle variabili di ambiente nella

/etc/anacrontab

forma di una assegnazione della stessa come nella shell. Al solito le righe vuote e tutto quelle

che segue un “ ” viene ignorato, mentre le righe restanti servono ad indicare le operazioni da

#

eseguire.

Ciascuna operazione deve essere specificata in una riga con 4 campi separati da spazi, che

indicano rispettivamente: una periodicità di esecuzione (in numero di giorni), un ritardo iniziale

(in numero di minuti), una stringa di identificazione, ed il comando da eseguire. Il primo campo,

che indica la periodicità, può essere anche espresso in forma simbolica con i nomi ,

monthly weekly

e preceduti dal carattere “ ”. Un esempio di questo file, sempre preso dalla versione

daily @

installata su Debian Squeeze, è il seguente:

/etc/anacrontab

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# These replace cron’s entries

1 5 cron.daily nice run-parts --report /etc/cron.daily

7 10 cron.weekly nice run-parts --report /etc/cron.weekly

@monthly 15 cron.monthly nice run-parts --report /etc/cron.monthly

Il funzionamento di prevede che il comando legga la lista delle operazioni periodiche

anacron

da e controlli se queste sono state eseguite nel periodo di tempo indicato nel

/etc/anacrontab

primo campo. Il programma infatti mantiene una sua lista interna delle operazioni, in cui

registra anche l’ultima esecuzione effettuata, e se è passato più tempo di quello richiesto mette

in esecuzione il relativo comando dopo il ritardo indicato dal secondo campo, che viene utilizzato

per evitare di lanciare in contemporanea tutti i comandi relativi alle operazioni scadute.

Il programma legge il file all’avvio e poi resta in esecuzione come demone, ripetendo le

operazioni secondo la periodicità indicata, che però ha come granularità minima quella dei

giorni (viene cioè controllata solo la data e non l’ora). Questo, fintanto che la macchina è accesa,

garantisce la periodicità nei termini indicati, ma consente, se ad esempio si spegne la macchina

la notte, di eseguire i compiti rimasti sospesi al riavvio successivo non essendo vincolato, come

, ad un orario specifico.

cron

Si tenga presente però che a parte gestire le operazioni periodiche in questa modalità, anacron

non costituisce una alternativa a , sia per l’impossibilità di usare periodicità su tempi inferiori

cron

al giorno sia per l’impossibilità di indicare orari precisi di esecuzione, che sono necessari in molti

3. La configurazione dei servizi 181

casi. Al solito per i dettagli sul funzionamento e sulla configurazione, si consultino le relative

pagine di manuale con e .

man anacron man anacrontab

Oltre ai compiti relativi alla gestione del sistema, e programmati pertanto dall’ammini-

stratore che è l’unico che ha i privilegi per modificare , il servizio è in

cron

/etc/crontab

grado di eseguire anche operazioni richieste da un singolo utente. L’utente può creare un

suo personale tramite il comando , in questo caso i file vengono mantenuti in

crontab crontab

, e non sono accessibili direttamente ai singoli utenti se non appunto

/var/spool/cron/crontabs

attraverso detto comando.

Se si invoca con l’opzione questo invocherà l’editor predefinito con cui scrivere il

crontab -e

contenuto del proprio personale. Il default è l’uso di , a meno di non aver impostato

crontab vi

diversamente la variabile di ambiente . Il formato delle tabelle di personali è identico a

cron

EDITOR

quello di , con l’eccezione dell’assenza del sesto campo, che nel caso non è necessario

/etc/crontab

dato che l’utente è già ben definito.

Se lanciato senza opzioni prende come argomento un file da usare come tabella, di

crontab

cui legge il contenuto, che deve essere nella forma in cui lo si scriverebbe con l’editor, invece

usando “ ” come nome del file i dati verranno presi dallo Con invece si esegue

standard input.

- -r

la rimozione completa della tabella corrente, ma si faccia attenzione nell’uso dato che il comando

non chiede conferma. Infine con si potrà modificare (solo da parte dell’amministratore) la

-u

tabella dell’utente specificato come parametro.

Si può poi vedere la lista delle operazioni programmate usando l’opzione , che scrive sullo

-l

il contenuto corrente della tabella dell’utente. La versione usata da Debian

standard output cron

in realtà non stampa le righe di commento iniziale che avvisano di non modificare direttamente

il contenuto del in modo da poter riutilizzare l’output del comando direttamente come

crontab,

input per un successivo .

crontab -

Si tenga presente che l’amministratore può riservare l’uso del servizio solo ad alcuni

cron

utenti, creando il file , nel quale si devono elencare gli username degli utenti che

/etc/cron.allow

lo possono usare. Se il file non esiste è possibile vietare l’uso del servizio solo ad alcuni utenti

con la creazione del file che di nuovo dovrà contenere la lista degli username di

/etc/cron.deny

coloro che non possono usarlo. In assenza di detti file chiunque può usare il servizio.

3.2.2 Il servizio at

Abbiamo visto nella sezione precedente come si può programmare l’esecuzione periodica di co-

mandi con , esistono però anche necessità di avere una esecuzione semplicemente differita,

crontab

senza che questa debba essere periodica. Per provvedere a questo compito esiste un altro servizio,

chiamato dal nome del comando che permette di richiedere l’esecuzione di un programma ad

at

un tempo successivo. Il servizio comporta diverse modalità di gestione della esecuzione differita,

e vari programmi per la gestione della stessa.

Il servizio è realizzato dal demone , che come viene normalmente lanciato dagli script

atd cron

di avvio. Il demone controlla la presenza nelle code di programmi in attesa di essere eseguiti, e

li manda in esecuzione al tempo stabilito. Il demone può essere anche lanciato manualmente, e

prevede come opzioni che permette di impostare un intervallo di tempo minimo (il default è 60

-b

secondi) fra la messa in esecuzione di due successivi programmi e che permette di impostare

-l

manualmente un limite massimo per il carico della macchina, oltre il quale non saranno comunque

eseguiti i programmi, di default questo è pari a 1.5, ed ha senso cambiarlo solo in caso di macchine

3. La configurazione dei servizi 183

multiprocessore. Al solito per l’elenco completo delle opzioni si può fare riferimento alla pagina di

manuale.

Il comando di base, che permette di programmare l’esecuzione di un programma ad un dato

momento, è . Il comando vuole come argomento data ed ora in cui il programma specificato

at

deve essere messo in esecuzione; il nome di quest’ultimo viene letto dallo ma può

standard input

essere specificato tramite un file qualunque, passato come parametro per l’opzione . Le altre

-f

principali opzioni sono riportate in tab. 3.3, per l’elenco completo si può al solito consultare la

pagina di manuale.

Opzione Significato

indica il file da cui leggere il comando da eseguire.

-f stampa la lista dei lavori programmati (equivalente a ).

-l atq

job job id

rimuove il lavoro con (equivalente a ).

-d job atrm job

11

queue invia il comando sulla coda .

-q queue

invia un messaggio al completamento del lavoro programmato anche nel caso

-m non ci siano dati in uscita.

Tabella 3.3: Principali opzioni del comando .

at

Il comando supporta una grande varietà di formati per le modalità in cui si indica la data, fra

cui tutti quelli del comando (vedi sez. 2.4.3), più altre estensioni che permettono di usare

date

anche specificazioni in forma più discorsiva come ; una descrizione completa

at 1pm tomorrow

delle convenzioni utilizzabili si trova nel file . Una volta completata

/usr/share/doc/at/timespec

la programmazione il programma stampa sul terminale un valore numerico (detto ) che

job id

identifica il lavoro differito programmato dall’utente. Un esempio dell’uso di è il seguente:

at

at 18:00

picca