Per questo l'esecuzione di un comando può originare più di un processo; quindi
nella gestione del job control non si può far riferimento ai singoli processi.
Per questo il kernel prevede la possibilità di raggruppare più processi in un
-\textit{process group} (detto anche \textsl{raggruppamento}, vedi
+\textit{process group} (detto anche \textsl{raggruppamento di processi}, vedi
\secref{sec:sess_proc_group}) e la shell farà sì che tutti i processi che
-originano da una riga di comando appartengano allo stesso \textit{process
- group}, in modo che le varie funzioni di controllo, ed i segnali inviati dal
-terminale, possano fare riferimento ad esso.
+originano da una riga di comando appartengano allo stesso raggruppamento, in
+modo che le varie funzioni di controllo, ed i segnali inviati dal terminale,
+possano fare riferimento ad esso.
-In generale allora all'interno di una sessione avremo un eventuale (possono
-non esserci) \textit{process group} in \textit{foreground}, che riunisce i
+In generale allora all'interno di una sessione avremo un eventuale (può non
+esserci) \textit{process group} in \textit{foreground}, che riunisce i
processi che possono accedere al terminale, e più \textit{process group} in
\textit{background}, che non possono accedervi. Il job control prevede che
quando un processo appartenente ad un raggruppamento in \textit{background}
tastiera inviati dal terminale che vengono inviati a tutti i processi del
raggruppamento in \textit{foreground}. In particolare \cmd{C-z} interrompe
l'esecuzione del comando, che può poi essere mandato in \textit{background}
-con il comando \cmd{bg}. Il comando \cmd{fg} consente invece di mettere in
-\textit{foreground} un comando precedentemente lanciato in
-\textit{background}.
+con il comando \cmd{bg}.\footnote{si tenga presente che \cmd{bg} e \cmd{fg}
+ sono parole chiave che indicano comandi interni alla shell, e nel caso non
+ comportano l'esecuzione di un programma esterno.} Il comando \cmd{fg}
+consente invece di mettere in \textit{foreground} un comando precedentemente
+lanciato in \textit{background}.
Di norma la shell si cura anche di notificare all'utente (di solito prima
-della stampa a video del prompt) lo stato dei vari processi, essa infatti usa
-le caratteristiche della funzione \func{waitpid} (si riveda quanto detto in
-\secref{sec:proc_wait}) per verificare quali gruppi di processi sono bloccati
-e quali sono terminati.
+della stampa a video del prompt) lo stato dei vari processi; essa infatti sarà
+in grado, grazie all'uso di \func{waitpid}, di rilevare sia i processi che
+sono terminati, sia i raggruppamenti che sono bloccati (in questo caso usando
+l'opzione \macro{WUNTRACED}, secondo quanto illustrato in
+\secref{sec:proc_wait}).
\subsection{I \textit{process group} e le \textsl{sessioni}}
\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 gruppo 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 gruppo, che
-si incarica di lanciare tutti gli altri. Un nuovo gruppo 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 è:
+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.
\end{prototype}
La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo
-corrente, rende questo \textit{process leader} di un nuovo gruppo, tutti i
-successivi processi da esso creati apparterranno (a meno di non cambiare di
-nuovo il \acr{pgid}) al nuovo gruppo. È possibile invece spostare un processo
-da un gruppo ad un altro con la funzione \func{setpgid}, il cui prototipo è:
+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 setpgid(pid\_t pid, pid\_t pgid)}
Assegna al \acr{pgid} del processo \param{pid} il valore \param{pgid}.
\textit{process group} che è nella stessa sessione del processo chiamante.
Inoltre la funzione può essere usata soltanto sul processo corrente o su uno
dei suoi figli, ed in quest'ultimo caso ha successo soltanto se questo non ha
-ancora eseguito una \func{exec}. Specificando un valore nullo per \param{pid}
-si indica il processo corrente, mentre specificando un valore nullo per
-\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del
-processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0,
- 0)}.
+ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata
+ dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in
+ \var{task\_struct}.} Specificando un valore nullo per \param{pid} si indica
+il processo corrente, mentre specificando un valore nullo per \param{pgid} si
+imposta il \textit{process group} al valore del \acr{pid} del processo
+selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}.
Di norma questa funzione viene usata dalla shell quando si usano delle
pipeline, per mettere nello stesso process group tutti i programmi lanciati su
sessione ad un processo è quello di crearne una nuova con l'uso di
\func{setsid}; il suo prototipo è:
\begin{prototype}{unistd.h}{pid\_t setsid(void)}
- Crea una nuova sessione sul processo corrente settandone \acr{sid} e
+ Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
\acr{pgid}.
\bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
- \acr{pgid} e \acr{pid} del processo concidono.}
+ \acr{pgid} e \acr{pid} del processo coincidono.}
\end{prototype}
La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
il precedente terminale di controllo viene cancellata, ed il processo che è
-divenuto un nuovo leader di sessione dovrà riottenere (qualora sia necessario,
-cosa che, come vedremo in \secref{sec:sess_daemon}, non è sempre vera), un
-terminale di controllo. In generale questo viene fatto automaticamente dal
-sistema quando viene aperto il primo terminale\footnote{a meno di non avere
- richiesto esplicitamente che questo non diventi un terminale di controllo
- con il flag \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux
- segue la semantica di SVr4; BSD invece richiede che il terminale venga
- allocato esplicitamente con una \func{ioctl} con il comando
- \macro{TIOCSCTTY}.} che diventa automaticamente il terminale di controllo,
+divenuto un nuovo leader di sessione dovrà riottenere\footnote{solo quando ciò
+ è necessario, cosa che, come vedremo in \secref{sec:sess_daemon}, non è
+ sempre vera.}, un terminale di controllo. In generale questo viene fatto
+automaticamente dal sistema\footnote{a meno di non avere richiesto
+ esplicitamente che questo non diventi un terminale di controllo con il flag
+ \macro{O\_NOCTTY} (vedi \secref{sec:file_open}). In questo Linux segue la
+ semantica di SVr4; BSD invece richiede che il terminale venga allocato
+ esplicitamente con una \func{ioctl} con il comando \macro{TIOCSCTTY}.}
+quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
+\file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
mentre il processo diventa il \textsl{processo di controllo} di quella
sessione.
In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
-sessione, ma solo quelli che fanno parte del cosiddetto gruppo di
+sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
-impostare il gruppo di \textit{foreground} di un terminale si usa la funzione
-\func{tcsetpgrp}, il cui prototipo è:
+impostare il raggruppamento di \textit{foreground} di un terminale si usa la
+funzione \func{tcsetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h}
\headdecl{termios.h}
un processo nella stessa sessione e con lo stesso terminale di controllo.
Come accennato in \secref{sec:sess_job_control_overview}, tutti i processi (e
-relativi gruppi) che non fanno parte del gruppo di \textit{foreground} sono
-detti in \textit{background}; se uno si essi cerca di accedere al terminale di
-controllo provocherà l'invio da parte del kernel di uno dei due segnali
-\macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato in
-lettura o scrittura) a tutto il suo \textit{process group}; dato che il
+relativi raggruppamenti) che non fanno parte del gruppo di \textit{foreground}
+sono detti in \textit{background}; se uno si essi cerca di accedere al
+terminale di controllo provocherà l'invio da parte del kernel di uno dei due
+segnali \macro{SIGTTIN} o \macro{SIGTTOU} (a seconda che l'accesso sia stato
+in lettura o scrittura) a tutto il suo \textit{process group}; dato che il
comportamento di default di questi segnali (si riveda quanto esposto in
-\secref{sec:sig_job_control}) è di bloccare il processo, di norma questo
-comporta che tutti verranno fermati, ma non si avranno condizioni di
-errore. Se però si bloccano o ignorano i due segnali citati, le funzioni di
-lettura e scrittura falliranno con un errore di \macro{EIO}.
-
-Un processo può contollare qual'è il gruppo di \textit{foreground} associato
+\secref{sec:sig_job_control}) è di fermare il processo, di norma questo
+comporta che tutti i membri del gruppo verranno fermati, ma non si avranno
+condizioni di errore.\footnote{la shell in genere notifica comunque un
+ avvertimento, avvertendo la presenza di processi bloccati grazie all'uso di
+ \func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
+funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
+
+Un processo può controllare qual'è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
processo di accedere direttamente al suo terminale di controllo attraverso il
file speciale \file{/dev/tty}, che per ogni processo è un sinonimo per il
proprio terminale di controllo. Questo consente anche a processi che possono
-aver rediretto l'output di accedere al terminale, pur non disponendo più del
-file descriptor originario; un caso tipico è il programma \cmd{crypt} che
-accetta la redirezione sullo standard input di un file da decrittare, ma deve
-poi leggere la password dal terminale.
+aver rediretto l'output di accedere al terminale di controllo, pur non
+disponendo più del file descriptor originario; un caso tipico è il programma
+\cmd{crypt} che accetta la redirezione sullo standard input di un file da
+decifrare, ma deve poi leggere la password dal terminale.
Un'altra caratteristica del terminale di controllo usata nel job control è che
utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
-\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà si che il kernel invii i
+\cmd{C-c}, \cmd{C-y} e \verb|C-\|) si farà sì che il kernel invii i
corrispondenti segnali (rispettivamente \macro{SIGTSTP}, \macro{SIGINT},
\macro{SIGQUIT} e \macro{SIGTERM}, trattati in \secref{sec:sig_job_control}) a
-tutti i processi del gruppo di \textit{foreground}; in questo modo la shell
-può gestire il blocco e l'interruzione dei vari comandi.
+tutti i processi del raggruppamento di \textit{foreground}; in questo modo la
+shell può gestire il blocco e l'interruzione dei vari comandi.
Per completare la trattazione delle caratteristiche del job control legate al
terminale di controllo, occorre prendere in considerazione i vari casi legati
Lo standard POSIX.1 prevede che quando il processo di controllo termina, che
ciò avvenga o meno per un \textit{hungup} del terminale (ad esempio si
potrebbe terminare direttamente la shell con \cmd{kill}) venga inviato un
-segnale di \macro{SIGHUP} ai processi del gruppo di foreground. In questo modo
-essi potranno essere avvisati che non esiste più un processo in grado di
-gestire il terminale (di norma tutto ciò comporta la terminazione anche di
-questi ultimi).
-
-Restano però gli eventuali processi in background, che non ricevono il segnale
-(in effetti se il terminale non serve più potrebbero proseguire fino al
-completamento della loro esecuzione). Il problema si pone per quelli che sono
-bloccati, o che si bloccano nell'accesso al terminale.
-
-In questa situazione si ha un cosiddetto \textit{orphaned process group};
-POSIX.1 lo definisce come un \textit{process group} i cui processi hanno come
-padri esclusivamente o altri processi nel gruppo, o processi fuori della
-sessione. Lo standard prevede che se la terminazione di un processo fa sì che
-un process group diventi orfano e se i suoi mebri sono bloccati, a tutti
-vengano inviati in sequenza i segnali di \macro{SIGHUP} e \macro{SIGCONT}.
+segnale di \macro{SIGHUP} ai processi del raggruppamento di foreground. In
+questo modo essi potranno essere avvisati che non esiste più un processo in
+grado di gestire il terminale (di norma tutto ciò comporta la terminazione
+anche di questi ultimi).
+
+Restano però gli eventuali processi in background, che non ricevono il
+segnale; in effetti se il terminale non dovesse più servire essi potrebbero
+proseguire fino al completamento della loro esecuzione; ma si pone il problema
+di come gestire quelli che sono bloccati, o che si bloccano nell'accesso al
+terminale, in assenza di un processo che sia in grado di effettuare il
+controllo dello stesso.
+
+Questa è la situazione in cui si ha quello che viene chiamato un
+\textit{orphaned process group}. Lo standard POSIX.1 lo definisce come un
+\textit{process group} i cui processi hanno come padri esclusivamente o altri
+processi nel raggruppamento, o processi fuori della sessione. Lo standard
+prevede inoltre che se la terminazione di un processo fa sì che un
+raggruppamento di processi diventi orfano e se i suoi membri sono bloccati, ad
+essi vengano inviati in sequenza i segnali di \macro{SIGHUP} e
+\macro{SIGCONT}.
La definizione può sembrare complicata, e a prima vista non è chiaro cosa
-tutto ciò abbia a che fare con il problema illustrato. Consideriamo allora
-cosa avviene di norma nel \textit{job control}: una sessione viene creata con
-\func{setsid} che crea anche un nuovo process group: per definizione
-quest'ultimo è sempre \textsl{orfano}, dato che il padre del leader di
-sessione è fuori dallo stesso. Questo è un caso limite, e non viene emesso
-nessun segnale perché quanto previsto dallo standard riguarda solo i
-raggruppamenti che diventano orfani alla terminazione di un processo.
-
-Il leader di sessione provvederà a creare nuovi process group che a questo
+tutto ciò abbia a che fare con il problema della terminazione del processo di
+controllo. Consideriamo allora cosa avviene di norma nel \textit{job
+ control}: una sessione viene creata con \func{setsid} che crea anche un
+nuovo process group: per definizione quest'ultimo è sempre \textsl{orfano},
+dato che il padre del leader di sessione è fuori dalla stessa e il nuovo
+process group contiene solo il leader di sessione. Questo è un caso limite, e
+non viene emesso nessun segnale perché quanto previsto dallo standard riguarda
+solo i raggruppamenti che diventano orfani in seguito alla terminazione di un
+processo.\footnote{l'emissione dei segnali infatti avviene solo nella fase di
+ uscita del processo, come una delle operazioni legate all'esecuzione di
+ \func{\_exit}, secondo quanto illustrato in \secref{sec:proc_termination}.}
+
+Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
punto non sono orfani in quanto esso resta padre per almeno uno dei processi
del gruppo (gli altri possono derivare dal primo). Alla terminazione del
leader di sessione però avremo che, come visto in
\secref{sec:proc_termination}, tutti i suoi figli vengono adottati da
\cmd{init}, che è fuori dalla sessione. Questo renderà orfani tutti i process
-group (a meno di non aver spostato con \func{setpgid} un processo da un gruppo
-ad un altro, cosa che di norma non viene fatta) crati direttamente dal leader
-di sessione i quali riceveranno, nel caso siano bloccati, i due segnali, in
-modo che essi vengano sbloccati da \macro{SIGCONT} e (se non vi è un gestore
-opportuno) terminati da \macro{SIGHUP}.
-
-
+group creati direttamente dal leader di sessione (a meno di non aver spostato
+con \func{setpgid} un processo da un gruppo ad un altro, cosa che di norma non
+viene fatta) i quali riceveranno, nel caso siano bloccati, i due segnali;
+\macro{SIGCONT} ne farà proseguire l'esecuzione, ed essendo stato nel
+frattempo inviato anche \macro{SIGHUP}, se non c'è un gestore per
+quest'ultimo, i processi bloccati verranno automaticamente terminati.
-
- che possa accorgersi
-(si ricordi che per farlo occorre usare \func{waitpid}) se i processi del
-\textit{process group} sono bloccati.
-
-
\subsection{Dal login alla shell}
\label{sec:sess_login}
connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
fine le differenze sono\footnote{in generale nel caso di login via rete o di
terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
- ha origine l'esecuzione della shell.} nel device cui il kernel associa i
+ ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
caso classico del terminale.
telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
\textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
- vitruali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
+ virtuali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
delle sue varianti), che permette di mettersi in ascolto su uno di questi
\func{setsid} per creare una nuova sessione ed un nuovo process group, e di
aprire il terminale (che così diventa il terminale di controllo della
sessione) in lettura sullo standard input ed in scrittura sullo standard
-output e sullo standard error; inoltre effettuarà, qualora servano, ulteriori
+output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
di login in maiuscolo, può effettuare la conversione automatica dell'input
in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
-ad eseguire con un'altra \func{exec} la shell di login, che si troverà con un
-ambiente già pronto e con file standard di \secref{sec:file_std_descr}
-impostati sul terminale, pronta ad eseguire i comandi fino all'uscita. Dato
-che il processo genitore resta sempre \cmd{init} quest'ultimo provvederà,
-ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty}
-per ripetere da capo tutto il procedimento.
-
-
-In generale quando con il contollo di sessione è la shell che assume il ruolo
-di processo di controllo, seleziona il gruppo di \textit{foregroud} e gestisce
-l'assegnazione dei process group ai programmi eseguiti sulla stessa riga di
-comando.
-
-Qualora un processo venga bloccato nella gestione della sessione, sia
-implicitamente, perché cerca di eseguire dell'I/O sul terminale mentre è in
-background, sia esplicitamente con l'uso di \cmd{C-z}, la shell è in grado di
-rilevare l'evento grazie all'uso di \func{waitpid} con l'opzione
-\macro{WUNTRACED}. In questo modo la shell può notificare (di solito prima
-della stampa del prompt, lo stato dei vari processi.
-
+ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
+già pronto con i file standard di \secref{sec:file_std_descr} impostati sul
+terminale, e pronta, nel ruolo di leader di sessione e di processo di
+controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
+in \secref{sec:sess_job_control_overview}.
+Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
+provvedere, ricevendo un \macro{SIGCHLD} all'uscita della shell quando la
+sessione di lavoro è terminata, a rilanciare \cmd{getty} sul terminale per
+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 di 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.
+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
+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 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.}
+
+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à 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 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 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
+ resti in uso e non sia possibile rimuoverla o smontare il filesystem che la
+ contiene.
+\item Impostare la maschera dei permessi (di solito con \code{umask(0)}) in
+ modo da non essere dipendenti dal valore ereditato da chi ha lanciato
+ originariamente il processo.
+\item Chiudere i file standard (o redirigerli verso \file{/dev/null}).
+\end{enumerate}
+
+
+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)}
+ Esegue le operazioni che distaccano il processo dal terminale di controllo e
+ lo fanno girare come demone.
+
+ \bodydesc{La funzione restituisce (nel nuovo processo) 0 in caso di
+ successo, e -1 in caso di errore, nel qual caso \var{errno} assumerà i
+ valori impostati dalle sottostanti \func{fork} e \func{setsid}.}
+\end{prototype}
-Questi programmi, che devono essere eseguiti in modalità non interattiva 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 uno al suo
-servizio).\footnote{NdT. ricontrollare, i miei ricordi di filosofia sono
- piuttosto datati.}
+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 imposta anche la directory di lavoro su
+\file{/}, se \param{noclose} è nullo i file standard vengono rediretti su
+\file{dev/null}; in caso di valori non nulli non viene eseguita nessuna altra
+azione.
\section{L'I/O su terminale}
\label{sec:sess_terminal_io}
-Esamineremo in questa sezione le peculiarità dell'I/O su terminale, tenendo
-conto delle
+Esamineremo in questa sezione le peculiarità dell'I/O eseguito sui terminali,
+tenendo conto delle differenze che quest'ultimi presentano rispetto ai normali
+file su disco.
+
+
%%% Local Variables:
projects / gapil.git / blobdiff