From: Simone Piccardi Date: Sun, 29 Sep 2002 17:01:01 +0000 (+0000) Subject: Correzioni varie X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=c590e94a4432aec4fc9659ba68d406f3c4779e26;p=gapil.git Correzioni varie --- diff --git a/session.tex b/session.tex index 9e159d0..ffc6946 100644 --- a/session.tex +++ b/session.tex @@ -571,46 +571,48 @@ ripetere da capo tutto il procedimento. Come sottolineato fin da \secref{sec:intro_base_concept}, in un sistema unix-like tutte le operazioni sono eseguite tramite processi, comprese quelle operazioni di sistema (come l'esecuzione dei comandi periodici, o la consegna -della posta, ed in generale tutti i programmi di servizio) che non hanno a che -fare con la gestione diretta dei comandi dell'utente. +della posta, ed in generale tutti i programmi di servizio) che non hanno +niente a che fare con la gestione diretta dei comandi dell'utente. Questi programmi, che devono essere eseguiti in modalità non interattiva e senza nessun intervento dell'utente, sono normalmente chiamati \textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli -che svolgevano vari compiti, di cui parlava Socrate (che sosteneva di averne +che svolgevano compiti vari, di cui parlava Socrate (che sosteneva di averne uno al suo servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia - sono piuttosto datati.} - -Nei sistemi che supportano il \textit{job control} eseguire un programma da -riga di comando comporta che esso venga associato ad un terminale di controllo -e mantenuto all'interno di una sessione, e anche se può essere mandato in -background e non eseguire nessun I/O su terminale, si avranno comunque tutte -le conseguenze che abbiamo appena visto in \secref{sec:sess_ctrl_term} (in -particolare all'uscita del leader di sessione). - -Per questo motivo un programma che deve funzionare come demone deve prendere -da solo i provvedimenti opportuni (come distaccarsi dal terminale e dalla -sessione) ad impedire interferenze da parte del sistema del \textit{job - contol}; questi sono riassunti in una lista di prescrizioni\footnote{ad - esempio sia Stevens in \cite{APUE}, che la \textit{Unix Programming FAQ} - \cite{UnixFAQ} ne riportano di sostanzialmente identiche.} da seguire quando -si scrive un demone. + sono piuttosto datati.} + +Se però si lancia un programma demone dalla riga di comando in un sistema che +supporta, come Linux, il \textit{job control} esso verrà comunque associato ad +un terminale di controllo e mantenuto all'interno di una sessione, e anche se +può essere mandato in background e non eseguire più nessun I/O su terminale, +si avranno comunque tutte le conseguenze che abbiamo appena visto in +\secref{sec:sess_ctrl_term} (in particolare l'invio dei segnali in +corrispondenza dell'uscita del leader di sessione). + +Per questo motivo un programma che deve funzionare come demone deve sempre +prendere autonomamente i provvedimenti opportuni (come distaccarsi dal +terminale e dalla sessione) ad impedire eventuali interferenze da parte del +sistema del \textit{job contol}; questi sono riassunti in una lista di +prescrizioni\footnote{ad esempio sia Stevens in \cite{APUE}, che la + \textit{Unix Programming FAQ} \cite{UnixFAQ} ne riportano di sostanzialmente + identiche.} da seguire quando si scrive un demone. Pertanto, quando si lancia un programma che deve essere eseguito come demone -occorrerà che esso compia le seguenti azioni: +occorrerà predisporlo in modo che esso compia le seguenti azioni: \begin{enumerate} \item Eseguire una \func{fork} e terminare immediatamente il processo padre proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che il processo non è un \textit{process group leader}, e si può chiamare \func{setsid} con successo. -\item Eseguire \func{setsid} per creare un nuovo raggruppamento ed una nuova - sessione di cui il processo è leader, e che non ha associato nessun +\item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo + raggruppamento di cui il processo è leader, che non ha associato nessun terminale di controllo. -\item Assicurarsi che al processo non venga associato nessun nuovo terminale - di controllo; questo può essere fatto sia avendo cura di usare sempre - l'opzione nell'aprire i file, che eseguendo una ulteriore \func{fork} - proseguendo nel figlio, che a questo punto non essendo più leader di - sessione non può più ottenere un terminale di controllo. +\item Assicurarsi che al processo non venga associato in seguito nessun nuovo + terminale di controllo; questo può essere fatto sia avendo cura di usare + sempre l'opzione \macro{O\_NOCTTY} nell'aprire i file di terminale, che + eseguendo una ulteriore \func{fork} proseguendo nel figlio, che a questo + punto non essendo più leader di sessione non può più ottenere un terminale + di controllo. \item Eseguire una \func{chdir} per impostare la directory di lavoro (su \file{/} o su una directory che contenga dei file necessari per il programma), per evitare che la directory da cui si è lanciato il processo @@ -623,7 +625,7 @@ occorrer \end{enumerate} -In Linux buona parte di queste azioni, possono venire eseguite invocando la +In Linux buona parte di queste azioni possono venire eseguite invocando la funzione \func{daemon}, introdotta per la prima volta in BSD4.4; il suo prototipo è: \begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)} @@ -637,9 +639,11 @@ prototipo La funzione esegue una \func{fork}, per uscire subito, con \func{\_exit} nel padre, mentre l'esecuzione prosegue nel figlio che esegue \func{setsid}. Se -\param{nochdir} è nullo la funzione importa anche la directory di lavoro su +\param{nochdir} è nullo la funzione imposta anche la directory di lavoro su \file{/}, se \param{noclose} è nullo i file standard vengono rediretti su -\file{dev/null}. +\file{dev/null}; in caso di valori non nulli non viene eseguita nessuna altra +azione. +