From 610213043730bb22bd5f00113ce267200dd153a6 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 21 Sep 2001 17:10:51 +0000 Subject: [PATCH] Finito di aspettare ... quasi. --- gapil.tex | 3 +- intro.tex | 5 +- macro.tex | 2 +- prochand.tex | 284 +++++++++++++++++++++++++++++++-------------- signal.tex | 5 +- sources/ForkTest.c | 4 +- 6 files changed, 210 insertions(+), 93 deletions(-) diff --git a/gapil.tex b/gapil.tex index 7fd9225..f3c1743 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 @@ -100,6 +100,7 @@ \include{filedir} \include{fileunix} \include{filestd} +\include{session} \include{signal} \include{ipc} \include{network} diff --git a/intro.tex b/intro.tex index 634c3cb..5dfa21a 100644 --- a/intro.tex +++ b/intro.tex @@ -19,7 +19,7 @@ In questa prima sezione faremo una panoramica sulla struttura di un sistema \textit{unix-like} come GNU/Linux. Chi avesse già una conoscenza di questa materia può tranquillamente saltare questa sezione. -Il concetto base di un sistema unix-like é quello di un nucleo del sistema (il +Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il cosiddetto \textit{kernel}) a cui si demanda la gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi anche la parte che prevede l'interazione con l'utente, deve venire realizzato @@ -433,5 +433,6 @@ numerico alla costante simbolica. In particolare si \end{lstlisting} \caption{Codice per la stampa del messaggio di errore standard.} - \label{fig:proc_fork_code} + \label{fig:intro_err_mess} \end{figure} + diff --git a/macro.tex b/macro.tex index 64b7656..5c69ae2 100644 --- a/macro.tex +++ b/macro.tex @@ -97,8 +97,8 @@ tab.~\thechapter.\theusercount} \newcommand{\funcdecl}[1]{\item\texttt{#1}\par} \newenvironment{functions} {% defining what is done by \begin - \center \footnotesize + \center \begin{minipage}[c]{14cm} \begin{description}{}{} diff --git a/prochand.tex b/prochand.tex index 23dd77c..3b79276 100644 --- a/prochand.tex +++ b/prochand.tex @@ -27,42 +27,85 @@ generazione di nuovi processi 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'è il \cmd{init} che è progenitore di tutti gli altri processi. \subsection{Una panoramica sulle funzioni di gestione} @@ -85,7 +128,7 @@ del processo. 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. @@ -138,9 +181,8 @@ Per questo motivo processo il processo di avvio (\cmd{init}) ha sempre il 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} @@ -160,11 +202,12 @@ generare un pathname univoco, che non potr 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}} @@ -327,7 +370,7 @@ Se eseguiamo il comando senza specificare attese (come si pu 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 @@ -382,7 +425,7 @@ che otterremo \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 @@ -604,12 +647,12 @@ termina il kernel controlla se 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 @@ -630,27 +673,28 @@ terminano, e come si pu 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 @@ -693,13 +737,15 @@ 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} @@ -719,40 +765,42 @@ caso di errore; \var{errno} pu \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 @@ -761,16 +809,82 @@ specchietto riportato in \ntab: \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) 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 l'OR binario di zero con le suddette +costanti. + +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{}}. Lo standard +POSIX.1 definisce una serie di macro di preprocessore da usare per analizzare +lo stato di uscita; esse sono definite in \file{} ed elencate in +\ntab\ (si tenga presente che queste macro prendono come parametro la +variabile di tipo \type{int} puntata da \var{status}). + + +\begin{table}[!htb] + \centering + \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 diff --git a/signal.tex b/signal.tex index cc8e1af..82e1452 100644 --- a/signal.tex +++ b/signal.tex @@ -225,8 +225,9 @@ segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione specificare una scelta fra le tre seguenti: \begin{itemize} -\item ignorare il segnale -\item utilizzare il manipolatore (\textit{signal handler}) specificato +\item ignorare il segnale. +\item catturare il segnale, ed utilizzare il manipolatore (\textit{signal + handler}) specificato. \item accettare l'azione di default per quel segnale. \end{itemize} diff --git a/sources/ForkTest.c b/sources/ForkTest.c index 5401e31..03ddf75 100644 --- a/sources/ForkTest.c +++ b/sources/ForkTest.c @@ -26,7 +26,7 @@ * * Usage: forktest -h give all info's * - * $Id: ForkTest.c,v 1.5 2001/09/19 17:10:49 piccardi Exp $ + * $Id: ForkTest.c,v 1.6 2001/09/21 17:10:51 piccardi Exp $ * ****************************************************************/ /* @@ -94,7 +94,7 @@ int main(int argc, char *argv[]) usage(); } nchild = atoi(argv[optind]); - printf("Test for forking %d child\n", nchild); + printf("Process %d: forking %d child\n", getpid(), nchild); /* loop to fork children */ for (i=0; i