Orale Parte 2 Ambienti di Programmazione

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.

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 manuale, trattate rispettivamente in sez. 2.2.2 e 2.4.2.

Su Debian è ancora presente il vecchio comando tzconfig, ma questo è deprecato in favore della riconfigurazione del pacchetto dei dati delle timezone con dpkg-reconfigure tzdata (vedi sez. 4.2.3), su RedHat occorre invece usare il comando dedicato system-config-date.

La gestione dell’esecuzione periodica di programmi per compiere operazioni nel sistema viene realizzata dal servizio chiamato cron, che è stato implementato attraverso l’uso dell’omonimo demone cron. Il demone ha il compito di svegliarsi ogni minuto ed eseguire ogni programma che è stato programmato per quel momento.

Il file di configurazione principale di cron è /etc/crontab, che contiene l’elenco delle operazioni periodiche generali da eseguire nel sistema. Il primo file controllato da cron per decidere se c’è 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 /etc/crontab, il programma controlla anche il contenuto della directory /etc/cron.d/ dove i vari pacchetti possono inserire i loro file per esigenze specifiche, 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 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 */2 nel 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 cron, non saranno necessariamente definite le usuali variabili 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 /usr/bin e /bin. Altre variabili definite da cron sono LOGNAME e HOME, che corrisponderanno al nome utente e alla directory personale dell’utente per 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 definizioni seguono la stessa sintassi che si usa nella shell, con la differenza che cron non esegue la variable expansion, per cui non si potrà fare riferimento ad altre variabili all’interno di una definizione.

Infine un ruolo particolare viene giocato dalla variabile MAILTO, che indica l’utente a cui inviare 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 MAILTO per indicare un altro destinatario. Se la variabile è definita, ma vuota, l’invio verrà disabilitato. Questo è il motivo per cui spesso nei comandi lanciati tramite cron viene eseguita una redirezione dello standard output su /dev/null da scartare eventuali dati in uscita.

Un esempio del contenuto del file /etc/crontab, preso dalla versione installata di default su una Debian Squeeze, è il seguente:

# 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 run-parts il cui scopo è effettuare l’esecuzione, in ordine alfabetico, degli script presenti nella 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 /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/. Occorre comunque fare attenzione, perché run-parts non esegue gli script il cui nome contiene caratteri diversi da 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 crontab mostrato nell’esempio viene fatto un controllo preventivo della presenza del comando anacron. Questo è un sostituto di cron utilizzato originariamente sulle macchine che non è previsto siano sempre accese, come le stazioni di lavoro, che 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 cron. L’installazione di default non prevede la presenza di questo programma, per cui il comando run-parts non sarà presente e verrà eseguito invece.

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 /etc/anacrontab che prevede di nuovo la possibilità di definire delle variabili di ambiente nella 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 daily preceduti dal carattere “@”. Un esempio di questo file, sempre preso dalla versione installata su Debian Squeeze, è il seguente:

# /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 anacron prevede che il comando legga la lista delle operazioni periodiche da /etc/anacrontab e controlli se queste sono state eseguite nel periodo di tempo indicato nel 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 cron, ad un orario specifico.

Si tenga presente però che a parte gestire le operazioni periodiche in questa modalità, anacron non costituisce una alternativa a cron, sia per l’impossibilità di usare periodicità su tempi inferiori al giorno sia per l’impossibilità di indicare orari precisi di esecuzione, che sono necessari in molti casi. Al solito per i dettagli sul funzionamento e sulla configurazione, si consultino le relative pagine di manuale con man anacron e man anacrontab.

Oltre ai compiti relativi alla gestione del sistema, e programmati pertanto dall’amministratore che è l’unico che ha i privilegi per modificare /etc/crontab, il servizio cron è in grado di eseguire anche operazioni richieste da un singolo utente. L’utente può creare un suo personale crontab tramite il comando crontab, in questo caso i file vengono mantenuti in /var/spool/cron/crontabs, e non sono accessibili direttamente ai singoli utenti se non appunto attraverso detto comando.

Se si invoca crontab con l’opzione -e questo invocherà l’editor predefinito con cui scrivere il contenuto del proprio personale crontab. Il default è l’uso di vi, a meno di non aver impostato diversamente la variabile di ambiente EDITOR. Il formato delle tabelle di crontab personali è identico a quello di /etc/crontab, con l’eccezione dell’assenza del sesto campo, che nel caso non è necessario dato che l’utente è già ben definito.

Se lanciato senza opzioni crontab prende come argomento un file da usare come tabella, di 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 standard input. Con -r invece si esegue la rimozione completa della tabella corrente, ma si faccia attenzione nell’uso dato che il comando non chiede conferma. Infine con -u si potrà modificare (solo da parte dell’amministratore) la tabella dell’utente specificato come parametro.

Si può poi vedere la lista delle operazioni programmate usando l’opzione -l, che scrive sullo standard output il contenuto corrente della tabella dell’utente. La versione usata da Debian cron in realtà non stampa le righe di commento iniziale che avvisano di non modificare direttamente il contenuto del crontab in modo da poter riutilizzare l’output del comando direttamente come input per un successivo crontab -.

Si tenga presente che l’amministratore può riservare l’uso del servizio cron solo ad alcuni utenti, creando il file /etc/cron.allow, nel quale si devono elencare gli username degli utenti che lo possono usare. Se il file non esiste è possibile vietare l’uso del servizio solo ad alcuni utenti con la creazione del file /etc/cron.deny che di nuovo dovrà contenere la lista degli username di coloro che non possono usarlo. In assenza di detti file chiunque può usare il servizio.

Il servizio at

Abbiamo visto nella sezione precedente come si può programmare l’esecuzione periodica di comandi con crontab. Esistono però anche necessità di avere una esecuzione semplicemente differita, senza che questa debba essere periodica. Per provvedere a questo compito esiste un altro servizio, chiamato at dal nome del comando che permette di richiedere l’esecuzione di un programma ad un tempo successivo. Il servizio at comporta diverse modalità di gestione della esecuzione differita, e vari programmi per la gestione della stessa.

Il servizio at è realizzato dal demone atd, che come cron viene normalmente lanciato dagli script 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 -b che permette di impostare un intervallo di tempo minimo (il default è 60 secondi) fra la messa in esecuzione di due successivi programmi e -l che permette di impostare 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 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, è at. Il comando vuole come argomento data ed ora in cui il programma specificato deve essere messo in esecuzione; il nome di quest’ultimo viene letto dallo standard input ma può essere specificato tramite un file qualunque, passato come parametro per l’opzione -f. Le altre principali opzioni sono riportate in tab. 3.3, per l’elenco completo si può al solito consultare la pagina di manuale.

Il comando at supporta una grande varietà di formati per le modalità in cui si indica la data, fra cui tutti quelli del comando date (vedi sez. 2.4.3), più altre estensioni che permettono di usare anche specificazioni in forma più discorsiva come at 1pm tomorrow; una descrizione completa delle convenzioni utilizzabili si trova nel file /usr/share/doc/at/timespec. Una volta completata la programmazione il programma stampa sul terminale un valore numerico (detto job id) che identifica il lavoro differito programmato dall’utente. Un esempio dell’uso di at è il seguente:

at 18:00