X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=741496827f564a4894f4b0d482b20d87e60e5199;hp=8a5d70cd95a51060857c37a0b17a0319c6f7151a;hb=4ad4523de32d786ae4c24ef157bd4b8fe4aac534;hpb=595863c4415b13434e12618069e9f57063cc2da7 diff --git a/prochand.tex b/prochand.tex index 8a5d70c..7414968 100644 --- a/prochand.tex +++ b/prochand.tex @@ -30,35 +30,35 @@ qualunque processo pu 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 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 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 è +Una seconda caratteristica di un sistema unix è 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 +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 è sempre stato generato da un +altro, 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 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 +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 +amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di 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). +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 +[piccardi@gont piccardi]$ pstree -n init-+-keventd |-kapm-idled |-kreiserfsd @@ -103,7 +103,7 @@ Dato che tutti i processi attivi nel sistema sono comunque generati da 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 +directory (si veda \secref{sec:file_file_struct}); in \curfig\ 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. @@ -189,6 +189,7 @@ ottenuti da programma usando le funzioni: \funcdecl{pid\_t getpid(void)} restituisce il pid del processo corrente. \funcdecl{pid\_t getppid(void)} restituisce il pid del padre del processo corrente. + Entrambe le funzioni non riportano condizioni di errore. \end{functions} esempi dell'uso di queste funzioni sono riportati in @@ -529,7 +530,7 @@ padre e figlio avranno in comune: \secref{tab:proc_uid_gid}). \item gli identificatori per il controllo di sessione: il \textit{process group id} e il \textit{session id} e il terminale di controllo. -\item i flag \acr{suid} e \acr{suid} (vedi \secref{sec:file_suid_sgid}). +\item i flag \acr{suid} e \acr{sgid} (vedi \secref{sec:file_suid_sgid}). \item la directory di lavoro e la directory radice (vedi \secref{sec:file_work_dir}). \item la maschera dei permessi di creazione (vedi \secref{sec:file_umask}). @@ -609,7 +610,7 @@ eseguite alla chiusura di un processo \item se il processo è un leader di sessione viene mandato un segnale di \macro{SIGHUP} a tutti i processi in background e il terminale di controllo viene disconnesso. -\item se la conclusione di un processe rende orfano un \textit{process group} +\item se la conclusione di un processo rende orfano un \textit{process group} ciascun membro del gruppo viene bloccato, e poi gli vengono inviati in successione i segnali \macro{SIGHUP} e \macro{SIGCONT}. \end{itemize} @@ -620,7 +621,7 @@ meccanismo scelto consiste nel riportare lo stato di terminazione (\textit{termination status}) di cui sopra al processo padre. Nel caso di conclusione normale, lo stato di uscita del processo viene -caratterizzato tremite il valore del cosiddetto \textit{exit status}, cioè il +caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala il programma non può specificare nessun \textit{exit status}, ed è il kernel @@ -637,7 +638,7 @@ secondo. La scelta di riportare al padre lo stato di terminazione dei figli, pur essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto -che sia così alla sua conclusione, dato che il padre protrebbe essere già +che sia così alla sua conclusione, dato che il padre potrebbe essere già terminato (si potrebbe avere cioè quello che si chiama un processo \textsl{orfano}). @@ -686,7 +687,7 @@ ma il cui stato di terminazione non 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ù +effettuerà la lettura dello stato di uscita anche questa informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi completamente conclusa. @@ -831,7 +832,7 @@ processo figlio non 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. +maschera 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 @@ -863,16 +864,16 @@ certezza che la chiamata a \func{wait} non si bloccher \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{WIFEXITED} ha restituito 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{WIFSIGNALED} ha restituito 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{WIFSIGNALED} ha restituito 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 @@ -880,7 +881,7 @@ certezza che la chiamata a \func{wait} non si bloccher 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. \\ + restituito un valore non nullo. \\ \hline \end{tabular} \caption{Descrizione delle varie macro di preprocessore utilizzabili per @@ -909,13 +910,16 @@ Si tenga conto che nel caso di conclusione anomala il valore restituito da \file{signal.h}, e stampato usando le funzioni definite in \secref{sec:sig_strsignal}. + +\subsection{Le funzioni \func{wait3} e \func{wait4}} +\label{sec:proc_wait4} + 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: +usate dal processo terminato e dai vari figli. Queste funzioni, che diventano +accessibili definendo la costante \macro{\_USE\_BSD}, sono: \begin{functions} \headdecl{sys/times.h} @@ -927,9 +931,9 @@ sono: 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}. + \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 @@ -965,7 +969,7 @@ struct rusage { \label{fig:proc_rusage_struct} \end{figure} In genere includere esplicitamente \file{} non è più necessario, -ma aumenta la portabiltà, e serve in caso si debba accedere ai campi di +ma aumenta la portabilità, 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}, @@ -1000,7 +1004,7 @@ front-end a \func{execve}. Il prototipo di quest'ultima *envp[])}. La funzione ritorna -1 solo in caso di errore, nel qual caso caso la - variabile \texttt{errno} è settata come: + \var{errno} può assumere i valori: \begin{errlist} \item \macro{EACCES} il file non è eseguibile, oppure il filesystem è montato in \cmd{noexec}, oppure non è un file normale o un interprete. @@ -1008,7 +1012,7 @@ front-end a \func{execve}. Il prototipo di quest'ultima è 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 + \item \macro{ENOENT} il file o una delle librerie dinamiche o l'interprete necessari per eseguirlo non esistono. \item \macro{ETXTBSY} L'eseguibile è aperto in scrittura da uno o più processi. @@ -1111,7 +1115,7 @@ indicato dal parametro \var{path}, che viene interpretato come il \begin{figure}[htb] \centering \includegraphics[width=13cm]{img/exec_rel.eps} - \caption{La inter-relazione fra le sei funzioni della famiglia \func{exec}} + \caption{La interrelazione fra le sei funzioni della famiglia \func{exec}} \label{fig:proc_exec_relat} \end{figure} @@ -1152,7 +1156,7 @@ 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 +può anche non essere resettato a \macro{SIG\_DFL} (si veda \secref{sec:sig_xxx}). La gestione dei file aperti dipende dal valore del flag di @@ -1186,7 +1190,7 @@ in genere questo \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] +chiamato come se si fosse eseguito il comando \cmd{interpreter [arg] filename}. Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è @@ -1248,7 +1252,7 @@ privilegi associati ai processi stessi. & \textit{supplementary group id} & indica i gruppi cui l'utente appartiene \\ \acr{suid} & \textit{saved user id} & indica l'utente \\ - \acr{sgid} & \textit{daved group id} & indica il gruppo \\ + \acr{sgid} & \textit{saved group id} & indica il gruppo \\ \acr{fsuid} & \textit{filesystem user id} & indica l'utente effettivo per il filesystem \\ \acr{fsgid} & \textit{filesystem group id} & indica il gruppo effettivo @@ -1269,7 +1273,7 @@ stessi per tutti i processi avviati in una sessione. In realt 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 +autenticazione lancia una shell per la quale setta questi identificatori ai valori corrispondenti all'utente che entra nel sistema. L'\textit{effective user id}, l'\textit{effective group id} e gli eventuali