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
\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}{pid\_t getsid(pid\_t pid)}
- Legge l'identificatore di sessione del processo \param{pid}.
-
- \bodydesc{La funzione restituisce l'identificatore (un numero positivo) in
- caso di successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà
- i valori:
- \begin{errlist}
- \item[\macro{ESRCH}] Il processo selezionato non esiste.
- \item[\macro{EPERM}] In alcune implementazioni viene restituito quando il
- processo selezionato non fa parte della stessa sessione del processo
- corrente.
- \end{errlist}
- }
-\end{prototype}
-
-Entrambi gli identificatori vengono inizializzati alla creazione di ciascun
-processo con lo stesso valore che hanno nel processo padre, per cui un
-processo appena creato appartiene sempre allo stesso raggruppamento e alla
-stessa sessione del padre. Vedremo poi come sia possibile creare più
-\textit{process group} all'interno della stessa sessione, e spostare i
-processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
-
-Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \textit{process group leader}, che è identificato dall'avere un
-\acr{pgid} uguale al suo \acr{pid}, in genere questo è il primo processo del
-raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo
-raggruppamento si crea con la funzione \func{setpgrp},\footnote{questa è la
- definizione di POSIX.1, BSD definisce una funzione con lo stesso nome, che
- però è identica a \func{setpgid}; nelle \acr{glibc} viene sempre usata
- sempre questa definizione, a meno di non richiedere esplicitamente la
- compatibilità all'indietro con BSD, definendo la macro
- \macro{\_BSD\_SOURCE}.} il cui prototipo è:
-\begin{prototype}{unistd.h}{int setpgrp(void)}
- Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente.
-
- \bodydesc{La funzione restituisce il valore del nuovo \textit{process
- group}.}
-\end{prototype}
-
-La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
-corrente, rende questo \textit{group leader} di un nuovo raggruppamento, tutti
-i successivi processi da esso creati apparterranno (a meno di non cambiare di
-nuovo il \acr{pgid}) al nuovo raggruppamento. È possibile invece spostare un
-processo da un raggruppamento ad un altro con la funzione \func{setpgid}, il
-cui prototipo è:
\begin{prototype}{unistd.h}{int daemon(int nochdir, int noclose)}
Esegue le operazioni che distaccano il processo dal terminale di controllo e
lo fanno girare come demone.
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.
+
projects / gapil.git / blobdiff