caratteristiche di unix (che esamineremo in dettaglio più avanti) è che
qualunque processo può a sua volta generarne altri, detti processi figli
(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero unico, il \acr{pid} (da \textit{process identifier}).
+numero unico, il cosiddetto \textit{process identifier} o, più brevemente,
+\acr{pid}.
Una seconda caratteristica è che la generazione di un processo è una
operazione separata rispetto al lancio di un programma. In genere la sequenza
-è sempre quella di creare un nuovo processo, il quale si eseguirà, in un passo
+è sempre quella di creare un nuovo processo, il quale eseguirà, in un passo
successivo, il programma voluto: questo è ad esempio quello che fa la shell
quando mette in esecuzione il programma che gli indichiamo nella linea di
comando.
Una terza caratteristica è che ogni processo viene sempre generato da un altro
-che viene chiamato processo genitore (\textit{parent process}). Questo vale
-per tutti i processi, con una eccezione (dato che ci deve essere un punto di
-partenza), esiste sempre infatti un processo speciale, che normalmente è
-\cmd{/sbin/init}, che viene lanciato dal kernel quando questo ha finito la
-fase di avvio, esso essendo il primo processo lanciato ha sempre il \acr{pid}
-uguale a 1 e non è figlio di nessuno.
-
-Questo è ovviamente un processo speciale, che in genere si occupa di far
-partire tutti gli processi altri necessari al funzionamento del sistema,
+che viene chiamato processo padre (\textit{parent process}). Questo vale per
+tutti i processi, con una sola eccezione: dato che ci deve essere un punto di
+partenza esiste sempre un processo speciale (che normalmente è
+\cmd{/sbin/init}), che viene lanciato dal kernel alla conclusione della fase
+di avvio, essendo questo il primo processo lanciato dal sistema ha sempre il
+\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+
+Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
+partire tutti gli altri processi necessari al funzionamento del sistema,
inoltre \cmd{init} è essenziale per svolgere una serie di compiti
amministrativi nelle operazioni ordinarie del sistema (torneremo si alcuni di
-essi in \secref{}) e non può mai essere terminato. La struttura del sistema
-comunque consente di lanciare al posto di \cmd{init} qualunque altro programma
-(e in casi di emergenza, ad esempio se il file di \cmd{init} si fosse
-corrotto, è possibile farlo ad esempio passando la riga \cmd{init=/bin/sh}
-all'avvio).
-
-Dato che tutti i processi successivi sono comunque generati da \cmd{init} o da
-suoi figli tutto ciò comporta che, i processi sono organizzati gerarchicamente
-dalla relazione fra genitori e figli, in maniera analoga a come i file sono
-organizzati in un albero di directory con alla base \file{/} (si veda
-\secref{sec:file_file_struct}); in questo caso alla base dell'albero c'è il
-processo \cmd{init} che è progenitore di ogni altro processo\footnote{in
- realtà questo non è del tutto vero, in Linux ci sono alcuni processi che pur
- comparendo come figli di init (ad esempio in \cmd{pstree}) sono generati
- direttamente dal kernel, come \cmd{keventd}, \cmd{kswapd}, etc.}.
+essi in \secref{sec:proc_termination}) e non può mai essere terminato. La
+struttura del sistema comunque consente di lanciare al posto di \cmd{init}
+qualunque altro programma (e in casi di emergenza, ad esempio se il file di
+\cmd{init} si fosse corrotto, è ad esempio possibile lanciare una shell al suo
+posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio).
+
+\begin{figure}[!htb]
+ \footnotesize
+\begin{verbatim}
+[piccardi@selidor piccardi]$ pstree -n
+init-+-keventd
+ |-kapm-idled
+ |-kreiserfsd
+ |-portmap
+ |-syslogd
+ |-klogd
+ |-named
+ |-rpc.statd
+ |-gpm
+ |-inetd
+ |-junkbuster
+ |-master-+-qmgr
+ | `-pickup
+ |-sshd
+ |-xfs
+ |-cron
+ |-bash---startx---xinit-+-XFree86
+ | `-WindowMaker-+-ssh-agent
+ | |-wmtime
+ | |-wmmon
+ | |-wmmount
+ | |-wmppp
+ | |-wmcube
+ | |-wmmixer
+ | |-wmgtemp
+ | |-wterm---bash---pstree
+ | `-wterm---bash-+-emacs
+ | `-man---pager
+ |-5*[getty]
+ |-snort
+ `-wwwoffled
+\end{verbatim} %$
+ \caption{L'albero dei processi, così come riportato dal comando
+ \cmd{pstree}.}
+ \label{fig:proc_tree}
+\end{figure}
+
+Dato che tutti i processi attivi nel sistema sono comunque generati da
+\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
+ vero, in Linux ci sono alcuni processi che pur comparendo come figli di
+ init, o con \acr{pid} successivi, sono in realtà generati direttamente dal
+ kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.)} si possono classificare i
+processi con la relazione padre/figlio in una organizzazione gerarchica ad
+albero, in maniera analoga a come i file sono organizzati in un albero di
+directory (si veda \secref{sec:file_file_struct}); in \nfig\ si è mostrato il
+risultato del comando \cmd{pstree} che permette di mostrare questa struttura,
+alla cui base c'è \cmd{init} che è progenitore di tutti gli altri processi.
\subsection{Una panoramica sulle funzioni di gestione}
Quando un processo ha concluso il suo compito o ha incontrato un errore non
risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in \secref{sec:proc_termination}). La vita del processo però
+quanto discusso in \secref{sec:proc_conclusion}). La vita del processo però
termina solo quando la notifica della sua conclusione viene ricevuta dal
processo padre, a quel punto tutte le risorse allocate nel sistema ad esso
associate vengono rilasciate.
Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui
sono stati creati, questo viene chiamato in genere \acr{ppid} (da
-\textit{parent process id}) ed è normalmente utilizzato per il controllo di
-sessione. Questi due identificativi possono essere ottenuti da programma
-usando le funzioni:
+\textit{parent process id}). Questi due identificativi possono essere
+ottenuti da programma usando le funzioni:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
processo che usi la stessa funzione.
Tutti i processi figli dello stesso processo padre sono detti
-\textit{sibling}, questa è un'altra delle relazioni usate nel controllo di
-sessione, in cui si raggruppano tutti i processi creati su uno stesso
-terminale una volta che si è effettuato il login. Torneremo su questo
-argomento in \secref{cap:terminal}, dove esamineremo tutti gli altri
-identificativi associati ad un processo relativi al controllo di sessione.
+\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
+ sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
+o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
+\secref{cap:session}, dove esamineremo i vari identificativi associati ad un
+processo e le varie relazioni fra processi utilizzate per definire una
+sessione.
\subsection{La funzione \func{fork}}
otterremo come output sul terminale:
\begin{verbatim}
[piccardi@selidor sources]$ ./forktest 3
-Test for forking 3 child
+Process 1963: forking 3 child
Spawned 1 child, pid 1964
Child 1 successfully executing
Child 1, parent 1963, exiting
\begin{verbatim}
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
-Test for forking 3 child
+Process 1967: forking 3 child
Child 1 successfully executing
Child 1, parent 1967, exiting
Test for forking 3 child
caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
avrà sempre un padre (nel caso \textsl{adottivo}) cui riportare il suo stato
-di terminazione. Come verifica di questo comportamento eseguiamo il comando
-\cmd{forktest -c2 3}, in questo modo ciascun figlio attenderà due secondi
-prima di uscire, il risultato è:
+di terminazione. Come verifica di questo comportamento possiamo eseguire il
+comando \cmd{forktest} imponendo a ciascun processo figlio due
+secondi di attesa prima di uscire, il risultato è:
\begin{verbatim}
[piccardi@selidor sources]$ ./forktest -c2 3
-Test for forking 3 child
+Process 1972: forking 3 child
Spawned 1 child, pid 1973
Child 1 successfully executing
Go to next child
in precedenza, essi riportano 1 come \acr{ppid}.
Altrettanto rilevante è il caso in cui il figlio termina prima del padre,
-questo perché non è detto che il padre possa ricevere immediatamente lo stato
-di terminazione, quindi il kernel deve comunque conservare una certa quantità
-di informazioni riguardo ai processi che sta terminando.
+perché non è detto che il padre possa ricevere immediatamente lo stato di
+terminazione, quindi il kernel deve comunque conservare una certa quantità di
+informazioni riguardo ai processi che sta terminando.
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
dal processo (vedi \secref{sec:intro_unix_time}) e lo stato di terminazione
-(NdA verificare esattamente cosa c'è!), mentre la memoria in uso ed i file
-aperti vengono rilasciati immediatamente. I processi che sono terminati, ma il
-cui stato di terminazione non è stato ancora ricevuto dal padre sono chiamati
-\textit{zombie}, essi restano presenti nella tabella dei processi ed in genere
-possono essere identificati dall'output di \cmd{ps} per la presenza di una
-\cmd{Z} nella colonna che ne indica lo stato. Quando il padre effettuarà la
-lettura dello stato di uscita anche questa informazione, non più necessaria,
-verrà scartata e la terminazione potrà dirsi completamente conclusa.
+\footnote{NdA verificare esattamente cosa c'è!}, mentre la memoria in uso ed i
+file aperti vengono rilasciati immediatamente. I processi che sono terminati,
+ma il cui stato di terminazione non è stato ancora ricevuto dal padre sono
+chiamati \textit{zombie}, essi restano presenti nella tabella dei processi ed
+in genere possono essere identificati dall'output di \cmd{ps} per la presenza
+di una \cmd{Z} nella colonna che ne indica lo stato. Quando il padre
+effettuarà la lettura dello stato di uscita anche questa informazione, non più
+necessaria, verrà scartata e la terminazione potrà dirsi completamente
+conclusa.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
-condizione: lanciamo il comando \cmd{forktest -e10 3 \&} in background,
-indicando al processo padre di aspettare 10 secondi prima di uscire; in questo
-caso, usando \cmd{ps} sullo stesso terminale (prima dello scadere dei 10
-secondi) otterremo:
+condizione: lanciamo il comando \cmd{forktest} in background, indicando al
+processo padre di aspettare 10 secondi prima di uscire; in questo caso, usando
+\cmd{ps} sullo stesso terminale (prima dello scadere dei 10 secondi)
+otterremo:
\begin{verbatim}
[piccardi@selidor sources]$ ps T
PID TTY STAT TIME COMMAND
vengono ereditati (compresi gli zombie) verranno adottati da \cmd{init}, il
quale provvederà a completarne la terminazione.
-Si tenga presente infine che siccome gli zombie sono processi già terminati,
-non c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è
-quella di terminare il processo che li ha generati, in modo che \cmd{init}
-possa adottarli e provvedere a concludere la terminazione.
+Si tenga presente infine che siccome gli zombie sono processi già usciti, non
+c'è modo di eliminarli con il comando \cmd{kill}; l'unica possibilità è quella
+di terminare il processo che li ha generati, in modo che \cmd{init} possa
+adottarli e provvedere a concludere la terminazione.
\subsection{Le funzioni \texttt{wait} e \texttt{waitpid}}
\label{sec:proc_wait}
-Abbiamo già visto in precedenza come uno degli usi possibili delle capacità
-multitasking di un sistema unix-like consiste nella creazione di programmi di
-tipo server, in cui un processo principale attende le richieste che vengono
-poi soddisfatte creando una serie di processi figli. Si è gia sottolineato
-come in questo caso diventi necessario gestire esplicitamente la conclusione
-dei vari processi figli; le funzioni deputate a questo sono sostanzialmente
-due, \func{wait} e \func{waitpid}. La prima, il cui prototipo è:
+Abbiamo già accennato come uno degli usi possibili delle capacità multitasking
+di un sistema unix-like consista nella creazione di programmi di tipo server,
+in cui un processo principale attende le richieste che vengono poi soddisfatte
+creando una serie di processi figli. Si è già sottolineato al paragrafo
+precedente come in questo caso diventi necessario gestire esplicitamente la
+conclusione dei vari processi figli onde evitare di riempire di
+\textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
+sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
+prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\end{errlist}
\end{functions}
è presente fin dalle prime versioni di unix; la funzione ritorna alla
-conclusione del primo figlio (o immediatamente se un figlio è già uscito), nel
+conclusione del primo figlio (o immediatamente se un figlio è già uscito). Nel
caso un processo abbia più figli il valore di ritorno permette di identificare
qual'è quello che è uscito.
Questa funzione però ha il difetto di essere poco flessibile, in quanto
-ritorna all'uscita di un figlio qualunque, per cui se si vuole attendere la
-conclusione di un processo specifico occorre predisporre un meccanismo che
-tenga conto dei processi già terminati, e ripeta la chiamata alla funzione nel
-caso il processo cercato sia ancora attivo.
-
-Per questo motivo lo standard Posix.1 ha introdotto \func{waitpid} che
-effettua lo stesso servizio, ma dispone di una serie di funzionalità più
-ampie; il suo prototipo è:
+ritorna all'uscita di un figlio qualunque. Nelle occasioni in cui è necessario
+attendere la conclusione di un processo specifico occorre predisporre un
+meccanismo che tenga conto dei processi già terminati, e ripeta la chiamata
+alla funzione nel caso il processo cercato sia ancora attivo.
+
+Per questo motivo lo standard POSIX.1 ha introdotto la funzione \func{waitpid}
+che effettua lo stesso servizio, ma dispone di una serie di funzionalità più
+ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
+lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
+questa funzione; il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\funcdecl{pid\_t waitpid(pid\_t pid, int * status, int options)}
-La funzione restituisce il \acr{pid} del figlio che è uscito, 0 se è stata
-specificata l'opzione \macro{WNOHANG} e il figlio non è uscito e -1 per un
+La funzione restituisce il \acr{pid} del processo che è uscito, 0 se è stata
+specificata l'opzione \macro{WNOHANG} e il processo non è uscito e -1 per un
errore, nel qual caso \var{errno} assumerà i valori:
\begin{errlist}
- \item \macro{EINTR} non è stata specificata l'opzione \macro{WNOHANG} e la
- funzione è stata interrotta da un segnale.
+ \item \macro{EINTR} se non è stata specificata l'opzione \macro{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item \macro{ECHILD} il processo specificato da \var{pid} non esiste o non è
figlio del processo chiamante.
\end{errlist}
\end{functions}
Le differenze principali fra le due funzioni sono che \func{wait} si blocca
-sempre fino a che un figlio non termina, mentre \func{waitpid} ha la
-possibilità si specificare un'opzione, \macro{WNOHANG} che ne previene il
-blocco, inoltre \func{waitpid} può specificare quale figlio attendere sulla
-base del valore soecificato tramite la variabile \var{pid} secondo lo
+sempre fino a che un processo figlio non termina, mentre \func{waitpid} ha la
+possibilità si specificare un'opzione \macro{WNOHANG} che ne previene il
+blocco; inoltre \func{waitpid} può specificare quale processo attendere sulla
+base del valore specificato tramite la variabile \var{pid}, secondo lo
specchietto riportato in \ntab:
\begin{table}[!htb]
\centering
\textbf{Valore} & \textbf{Significato}\\
\hline
\hline
- -1 & attende per un figlio qualsiasi, equivalente a \func{wait}\\
- > 0 & \\
- 0 & \\
- < -1& \\
+ $<-1$& attende per un figlio il cui \textit{process group} è uguale al
+ valore assoluto di \var{pid}. \\
+ $-1$ & attende per un figlio qualsiasi, usata in questa maniera è
+ equivalente a \func{wait}.\\
+ $0$ & attende per un figlio il cui \textit{process group} è uguale a
+ quello del processo chiamante. \\
+ $>0$ & attende per un figlio il cui \acr{pid} è uguale al
+ valore di \var{pid}.\\
\hline
\end{tabular}
- \caption{Significato del parametro \var{pid} della funzione \func{waitpid}.}
+ \caption{Significato dei valori del parametro \var{pid} della funzione
+ \func{waitpid}.}
\label{tab:proc_waidpid_pid}
\end{table}
+Il comportamento di \func{waitpid} può essere modificato passando delle
+opportune opzioni tramite la variabile \var{option}. I valori possibili sono
+il già citato \macro{WNOHANG}, che previene il blocco della funzione quando il
+processo figlio non è terminato, e \macro{WUNTRACED} (usata per il controllo
+di sessione, trattato in \capref{cha:session}) che fa ritornare la funzione
+anche per i processi figli che sono bloccati ed il cui stato non è stato
+ancora riportato al padre. Il valore dell'opzione deve essere specificato come
+mashera binaria ottenuta con l'OR delle suddette costanti con zero.
+
+La terminazione di un processo figlio è chiaramente un evento asincrono
+rispetto all'esecuzione di un programma e può avvenire in un qualunque
+momento, per questo motivo, come si è visto nella sezione precedente, una
+delle azioni prese dal kernel alla conclusione di un processo è quella di
+mandare un segnale di \macro{SIGCHLD} al padre. Questo segnale viene ignorato
+di default, ma costituisce il meccanismo di comunicazione asincrona con cui il
+kernel avverte un processo padre che uno dei suoi figli è terminato.
+
+In genere in un programma non si vuole essere forzati ad attendere la
+conclusione di un processo per proseguire, specie se tutto questo serve solo
+per leggerne lo stato di chiusura (ed evitare la presenza di \textit{zombie}),
+per questo la modalità più usata per chiamare queste funzioni è quella di
+utilizzarle all'interno di un \textit{signal handler} (torneremo sui segnali e
+su come gestire \macro{SIGCHLD} in \secref{sec:sig_sigwait_xxx}) nel qual
+caso, dato che il segnale è generato dalla terminazione un figlio, avremo la
+certezza che la chiamata a \func{wait} non si bloccherà.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|c|p{10cm}|}
+ \hline
+ \textbf{Macro} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
+ figlio che sia terminato normalmente. \\
+ \macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
+ stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
+ o come valore di ritorno di \func{main}). Può essere valutata solo se
+ \macro{WIFEXITED} ha restitituito un valore non nullo.\\
+ \macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
+ in maniera anomala a causa di un segnale che non è stato catturato (vedi
+ \secref{sec:sig_notification}).\\
+ \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
+ la terminazione anomala del processo. Può essere valutata solo se
+ \macro{WIFSIGNALED} ha restitituito un valore non nullo.\\
+ \macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
+ file si \textit{core dump}. Può essere valutata solo se
+ \macro{WIFSIGNALED} ha restitituito un valore non nullo\footnote{questa
+ macro non è definita dallo standard POSIX.1, ma è presente come estensione
+ sia in Linux che in altri unix}.\\
+ \macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
+ \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
+ l'opzione \macro{WUNTRACED}. \\
+ \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
+ il processo, Può essere valutata solo se \macro{WIFSTOPPED} ha
+ restitituito un valore non nullo. \\
+ \hline
+ \end{tabular}
+ \caption{Descrizione delle varie macro di preprocessore utilizzabili per
+ verificare lo stato di terminazione \var{s} di un processo.}
+ \label{tab:proc_status_macro}
+\end{table}
-Come abbiamo appena visto una delle azioni prese dal kernel alla terminazione
-di un processo è quella di salvarne lo stato e mandare un segnale di
-\macro{SIGCHLD} al padre (torneremo su questa parte in \secref{sec:sig_xxx}).
+Entrambe le funzioni restituiscono lo stato di terminazione del processo
+tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
+può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
+dipende dall'implementazione, e tradizionalmente alcuni bit sono riservati per
+memorizzare lo stato di uscita (in genere 8) altri per indicare il segnale che
+ha causato la terminazione (in caso di conclusione anomala), uno per indicare
+se è stato generato un core file, etc.\footnote{le definizioni esatte si
+ possono trovare in \file{<bits/waitstatus.h} ma questo file non deve mai
+ essere usato direttamente, esso viene incluso attraverso
+ \file{<sys/wait.h>}}. Lo standard POSIX.1 definisce una serie di macro di
+preprocessore da usare per analizzare lo stato di uscita; esse sono definite
+sempre in \file{<sys/wait.h>} ed elencate in \curtab\ (si tenga presente che
+queste macro prendono come parametro la variabile di tipo \type{int} puntata
+da \var{status}).
+
+Si tenga conto che nel caso di conclusione anomala il valore restituito da
+\macro{WTERMSIG} può essere controllato contro le costanti definite in
+\file{signal.h}, e stampato usando le funzioni definite in
+\secref{sec:sig_strsignal}.
+
+Linux, seguendo una estensione di BSD, supporta altre due funzioni per la
+lettura dello stato di terminazione di un processo, analoghe a \func{wait} e
+\func{waitpid}, ma che prevedono un ulteriore parametro attraverso il quale il
+kernel può restituire al processo padre ulteriori informazioni sulle risorse
+usate dal processo terminato e dai vari figli.
+Queste funzioni diventano accessibili definendo la costante \macro{\_USE\_BSD}
+sono:
+\begin{functions}
+ \headdecl{sys/times.h}
+ \headdecl{sys/types.h}
+ \headdecl{sys/wait.h}
+ \headdecl{sys/resource.h}
+ \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
+ * rusage)}
+ La funzione è identica a \func{waitpid} sia per comportamento che per i
+ valori dei parametri, ma restituisce in \var{rusage} un sommario delle
+ risorse usate dal processo (per i dettagli vedi \secref{sec:xxx_limit_res})
+ \funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
+ Prima versione, equivalente a \func{wait4(-1, \&status, opt, rusage)} ormai
+ deprecata in favore di \func{wait4}.
+\end{functions}
+la struttura \type{rusage} è definita in \file{sys/resource.h}, e viene
+utilizzata anche dalla funzione \func{getrusage} per ottenere le risorse di
+sistema usate dal processo; in Linux è definita come:
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{15cm}
+ \begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+struct rusage {
+ struct timeval ru_utime; /* user time used */
+ struct timeval ru_stime; /* system time used */
+ long ru_maxrss; /* maximum resident set size */
+ long ru_ixrss; /* integral shared memory size */
+ long ru_idrss; /* integral unshared data size */
+ long ru_isrss; /* integral unshared stack size */
+ long ru_minflt; /* page reclaims */
+ long ru_majflt; /* page faults */
+ long ru_nswap; /* swaps */
+ long ru_inblock; /* block input operations */
+ long ru_oublock; /* block output operations */
+ long ru_msgsnd; /* messages sent */
+ long ru_msgrcv; /* messages received */
+ long ru_nsignals; ; /* signals received */
+ long ru_nvcsw; /* voluntary context switches */
+ long ru_nivcsw; /* involuntary context switches */
+};
+ \end{lstlisting}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \texttt{rusage} per la lettura delle informazioni dei
+ delle risorse usate da un processo.}
+ \label{fig:proc_rusage_struct}
+\end{figure}
+In genere includere esplicitamente \file{<sys/time.h>} non è più necessario,
+ma aumenta la portabiltà, e serve in caso si debba accedere ai campi di
+\var{rusage} definiti come \type{struct timeval}. La struttura è ripresa dalla
+versione 4.3 Reno di BSD, attualmente (con il kernel 2.4.x) i soli campi che
+sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
+\var{ru\_majflt}, e \var{ru\_nswap}.
\subsection{Le funzioni \texttt{exec}}
\label{sec:proc_exec}
+Abbiamo già detto che una delle modalità principali con cui si utilizzano i
+processi in unix è quella di usarli per lanciare nuovi programmi: questo viene
+fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un
+processo chiama una di queste funzioni esso viene completamente sostituito dal
+nuovo programma; il \acr{pid} del processo non cambia, dato che non viene
+creato un nuovo processo, la funzione semplicemente rimpiazza lo stack, o
+heap, i dati ed il testo del processo corrente con un nuovo programma letto da
+disco.
+
+Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
+famiglia di funzioni) che possono essere usate per questo compito, che in
+realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
+front-end a \func{execve}. Il prototipo di quest'ultima è:
+
+\begin{prototype}{unistd.h}
+{int execve(const char * filename, char * const argv [], char * const envp[])}
+
+ La funzione esegue il file o lo script indicato da \var{filename},
+ passandogli la lista di argomenti indicata da \var{argv} e come ambiente la
+ lista di stringhe indicata da \var{envp}; entrambe le liste devono essere
+ terminate da un puntatore nullo. I vettori degli argomenti e dell'ambiente
+ possono essere acceduti dal nuovo programma quando la sua funzione
+ \func{main} è dichiarata nella forma \func{main(int argc, char *argv[], char
+ *envp[])}.
+
+ La funzione ritorna -1 solo in caso di errore, nel qual caso caso la
+ variabile \texttt{errno} è settata come:
+ \begin{errlist}
+ \item \macro{EACCES} il file non è eseguibile, oppure il filesystem è
+ montato in \cmd{noexec}, oppure non è un file normale o un interprete.
+ \item \macro{EPERM} il file ha i bit \acr{suid} o \acr{sgid} ma l'utente non
+ è root o il filesystem è montato con \cmd{nosuid}, oppure
+ \item \macro{ENOEXEC} il file è in un formato non eseguibile o non
+ riconosciuto come tale, o compilato per un'altra architettura.
+ \item \macro{ENOENT} il file o una delle librerie dinamiche o l'inteprete
+ necessari per eseguirlo non esistono.
+ \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più
+ processi.
+ \item \macro{EINVAL} L'eseguibile ELF ha più di un segmento
+ \macro{PF\_INTERP}, cioè chiede di essere eseguito da più di un interprete.
+ \item \macro{ELIBBAD} Un interprete ELF non è in un formato riconoscibile.
+ \end{errlist}
+ ed inoltre anche \macro{EFAULT}, \macro{ENOMEM}, \macro{EIO},
+ \macro{ENAMETOOLONG}, \macro{E2BIG}, \macro{ELOOP}, \macro{ENOTDIR},
+ \macro{ENFILE}, \macro{EMFILE}.
+\end{prototype}
+
+Le altre funzioni della famiglia servono per fornire all'utente una serie
+possibile di diverse interfacce per la creazione di un nuovo processo. I loro
+prototipi sono:
+
+\begin{functions}
+\headdecl{unistd.h}
+\funcdecl{int execl(const char *path, const char *arg, ...)}
+\funcdecl{int execv(const char *path, char *const argv[])}
+\funcdecl{int execle(const char *path, const char *arg, ..., char
+* const envp[])}
+\funcdecl{int execlp(const char *file, const char *arg, ...)}
+\funcdecl{int execvp(const char *file, char *const argv[])}
+
+Sostituiscono l'immagine corrente del processo con quella indicata nel primo
+argomento. I parametri successivi consentono di specificare gli argomenti a
+linea di comando e l'ambiente ricevuti dal nuovo processo.
+
+Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual
+caso \var{errno} andrà ad assumere i valori visti in precedenza per
+\func{execve}.
+\end{functions}
+
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
+riferimento allo specchietto riportato in \ntab. La prima differenza riguarda
+le modalità di passaggio dei parametri che poi andranno a costituire gli
+argomenti a linea di comando (cioè i valori di \var{argv} e \var{argc} visti
+dalla funzione \func{main} del programma chiamato).
+
+Queste modalità sono due e sono riassunte dagli mnenonici \func{v} e \func{l}
+che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
+gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
+stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
+questo vettore \emph{deve} essere terminato da un puntatore nullo.
+
+Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
+lista di puntatori, nella forma:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+ char * arg0, char * arg1, ..., char * argn, NULL
+\end{lstlisting}
+che deve essere terminata da un puntatore nullo. In entrambi i casi vale la
+convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
+per indicare il nome del file che contiene il programma che verrà eseguito.
+
+\begin{table}[!htb]
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|c|c|c||c|c|c|}
+ \hline
+ \multicolumn{1}{|c|}{\textbf{Caratteristiche}} &
+ \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
+ \hline
+ &\func{execl\ }&\func{execlp}&\func{execle}
+ &\func{execv\ }& \func{execvp}& \func{execve} \\
+ \hline
+ \hline
+ argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
+ argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
+ \hline
+ filename completo &&$\bullet$&&&$\bullet$& \\
+ ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
+ \hline
+ ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
+ uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
+ \hline
+ \end{tabular}
+ \caption{Confronto delle caratteristiche delle varie funzioni della
+ famiglia \func{exec}.}
+ \label{tab:proc_exec_scheme}
+\end{table}
+
+La seconda differenza fra le funzioni riguarda le modalità con cui si
+specifica il programma che si vuole eseguire. Con lo mnemonico \func{p} si
+indicano le due funzioni che replicano il comportamento della shell nello
+specificare il comando da eseguire; quando il parametro \var{file} non
+contiene una \file{/} esso viene considerato come un nome di programma, e
+viene eseguita automaticamente una ricerca fra i file presenti nella lista di
+directory specificate dalla variabile di ambiente \var{PATH}. Il file che
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore di
+permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un
+\macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori
+directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file
+viene finalmente restituito \macro{EACCESS}.
+
+Le altre quattro funzioni si limitano invece a cercare di eseguire il file
+indicato dal parametro \var{path}, che viene interpretato come il
+\textit{pathname} del programma.
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=13cm]{img/exec_rel.eps}
+ \caption{La inter-relazione fra le sei funzioni della famiglia \func{exec}}
+ \label{fig:proc_exec_relat}
+\end{figure}
+
+
+La terza differenza è come viene passata la lista delle variabili di ambiente.
+Con lo mnemonico \func{e} vengono indicate quelle funzioni che necessitano di
+un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
+a riga di comando (terminato quindi da un \macro{NULL}), le altre usano il
+valore della variabile \var{environ} (vedi \secref{sec:proc_environ}) del
+processo di partenza per costruire l'ambiente.
+
+Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
+\func{exec} assume anche una serie di altre proprietà del processo chiamante;
+la lista completa è la seguente:
+\begin{itemize}
+\item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID}
+ (\acr{ppid}).
+\item il \textit{real user ID} ed il \textit{real group ID} (vedi
+ \secref{sec:proc_user_group}).
+\item i \textit{supplementary group ID} (vedi \secref{sec:proc_user_group}).
+\item il \textit{session ID} ed il \textit{process group ID} (vedi
+ \secref{sec:sess_xxx}).
+\item il terminale di controllo (vedi \secref{sec:sess_xxx}).
+\item il tempo restante ad un allarme.
+\item la directory radice e la directory di lavoro corrente (vedi
+ \secref{sec:file_work_dir}).
+\item la maschera di creazione dei file (\var{umask}, vedi
+ \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
+ \secref{sec:file_xxx}).
+\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
+ \secref{sec:sig_xxx}).
+\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
+\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
+ \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+\end{itemize}
+
+Oltre a questo i segnali che sono stati settati per essere ignorati nel
+processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
+gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+può anche non essere resettatto a \macro{SIG\_DFL} (si veda
+\secref{sec:sig_xxx}).
+
+La gestione dei file aperti dipende dal valore del flag di
+\textit{close-on-exec} per ciascun file descriptor (si veda
+\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+altri file restano aperti. Questo significa che il comportamento di default è
+che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
+esplicita a \func{fcntl} che setti il suddetto flag.
+
+Per le directory lo standard POSIX.1 richiede che esse vengano chiuse
+attraverso una \func{exec}, in genere questo è fatto dalla funzione
+\func{opendir} che effettua da sola il settaggio del flag di
+\textit{close-on-exec} sulle directory che apre, in maniera trasparente
+all'utente.
+
+Abbiamo detto che il \textit{real user ID} ed il \textit{real group ID}
+restano gli stessi all'esecuzione di \func{exec}; lo stesso vale per
+l'\textit{effective user ID} ed l'\textit{effective group ID}, tranne il caso
+in cui il file che si va ad eseguire ha o il \acr{suid} bit o lo \acr{sgid}
+bit settato, nel qual caso \textit{effective user ID} e \textit{effective
+ group ID} vengono settati rispettivamente all'utente o al gruppo cui il file
+appartiene (per i dettagli vedi \secref{sec:proc_perms}).
+
+Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
+condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
+programma per caricare le librerie necessarie ed effettuare il link
+dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
+dinamiche viene usato l'interprete indicato nel segmento \macro{PT\_INTERP},
+in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
+\emph{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
+\emph{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
+una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
+deve esse un valido programma (binario, non un altro script) che verrà
+chiamato come se si fosse eseguitio il comando \cmd{interpreter [arg]
+ filename}.
+
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+basato il controllo dei processi in unix: con \func{fork} si crea un nuovo
+processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
+\func{wait} si effettua e si gestisce la conclusione dei programmi. Tutte le
+altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
+parametri connessi ai processi.
\subsection{Utente e gruppo di un processo}
\label{sec:proc_user_group}
-Abbiamo già accennato in \secref{sec:intro_multiuser} ad ogni utente ed gruppo
-sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid} che li
-contraddistinguono nei confronti del kernel. Questi identificatori stanno alla
-base del sistema di permessi e protezioni di un sistema unix, e vengono usati
-anche nella gestione dei privilegi di accesso dei processi.
+Abbiamo già accennato in \secref{sec:intro_multiuser} che ad ogni utente e
+gruppo sono associati due identificatori univoci, lo \acr{uid} e il \acr{gid}
+che li contraddistinguono nei confronti del kernel. Questi identificatori
+stanno alla base del sistema di permessi e protezioni di un sistema unix, e
+oltre che per il controllo di accesso ai file vengono usati anche nella
+gestione dei privilegi di accesso dei processi.
In realtà ad ogni processo è associato un certo numero di identificatori, il
cui elenco è riportato \ntab, in genere questi derivano direttamente
\acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
gestione dei privilegi associati ai processi stessi.
\begin{table}[htb]
+ \footnotesize
\centering
- \begin{tabular}[c]{|c|l|l|}
+ \begin{tabular}[c]{|c|l|p{8cm}|}
\hline
- Sigla & Significato & Utilizzo \\
+ \textbf{Sigla} & \textbf{Significato} & \textbf{Utilizzo} \\
\hline
\hline
\acr{ruid} & \textit{real user id} & indica l'utente reale che ha lanciato
Il \textit{real user id} e il \textit{real group id} indicano l'utente che ha
lanciato il processo, e vengono settati al login al valore standard di
\acr{uid} e \acr{gid} dell'utente letti direttamente da \file{/etc/passwd}.
-Questi non vengono mai cambiati nella creazione di nuovi processi e restano
-sempre gli stessi per tutti i processi avviati in una sessione. In realtà è
-possibile modificarli (vedi \secref{sec:proc_setuid}), ma solo per un processo
-che abbia i privilegi di amministratore (ed è così infatti che \cmd{login},
-che gira con i privilegi di amministratore, li setta ai valori corrispondenti
-all'utente che entra nel sistema).
+
+Esso servono ad identificare l'utente che ha lanciato il processo e non
+vengono mai cambiati nella creazione di nuovi processi restando sempre gli
+stessi per tutti i processi avviati in una sessione. In realtà vedremo che è
+possibile possibile modificarli (in \secref{sec:proc_setuid}), ma solo ad un
+processo che abbia i privilegi di amministratore; questa possibilità è usata
+ad esempio da \cmd{login} che una volta completata la procedura di
+autenticazione lancia una shell per la quale setta questi indetificatoru ai
+valori corrispondenti all'utente che entra nel sistema.
L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali
-\textit{supplementary group id} sono gli identificativi usati per il controllo
-di accesso ai file secondo quanto descritto in dettaglio in
-\secref{sec:file_perm_overview}. Normalmente sono uguali al \textit{real user
- id} e al \textit{real group id}, a meno che il file posto in esecuzione non
-abbia i bit \acr{suid} o \acr{sgid} settati, nel qual caso vengono settati
-rispettivamente all'\acr{uid} e \acr{gid} del file.
+\textit{supplementary group id} sono invece gli identificatori usati per il
+controllo di accesso ai file (secondo quanto descritto in dettaglio in
+\secref{sec:file_perm_overview}). Normalmente essi sono uguali al \textit{real
+ user id} e al \textit{real group id}, a meno che il file posto in esecuzione
+non abbia o il bit \acr{suid} o il bit \acr{sgid} settato, in questo caso alla
+la funzione \func{exec} (vedi \secref{}) li setta rispettivamente ai valori
+dell'\acr{uid} e del \acr{gid} cui appartiene il file.
Il \textit{saved user id} e il \textit{saved group id} sono copie
dell'\textit{effective user id} e dell'\textit{effective group id} del
-processo padre, e vengono settati all'avvio del processo, prima che
-\textit{effective user id} e \textit{effective group id} vengano modificati
-per tener conto di eventuali \acr{suid} o \acr{sgid}.
+processo padre, e vengono settati dalla funzione \func{exec} all'avvio del
+processo, prima che \textit{effective user id} e \textit{effective group id}
+vengano modificati per tener conto di eventuali \acr{suid} o \acr{sgid}, essi
+quindi consentono di tenere traccia di quale fossero l'utente originale.
\subsection{Le funzioni \texttt{setuid} e \texttt{setgid}}
\subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
\label{sec:proc_seteuid}
+
+\subsection{Le \textit{race condition}}
+\label{sec:proc_race_cond}
+
+Si definisce una \textit{race condition} il caso in cui diversi processi
+stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
+viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
+l'ordine di esecuzione di un processo, senza appositi meccanismi di
+sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
+fonti di errori molto subdoli, che possono verificarsi solo in condizioni
+particolari e quindi difficilmente riproducibili.
+
+
projects / gapil.git / blobdiff