X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=c9e4e156feda9fe814caf0bd04beb171ef61b093;hp=3b79276dcf2a0fff0513c72eb72fb78ff9bcf3f0;hb=992e4ddc3eb4351007fac08cb852297069f759b6;hpb=610213043730bb22bd5f00113ce267200dd153a6 diff --git a/prochand.tex b/prochand.tex index 3b79276..c9e4e15 100644 --- a/prochand.tex +++ b/prochand.tex @@ -105,7 +105,7 @@ 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. +alla cui base c'è \cmd{init} che è progenitore di tutti gli altri processi. \subsection{Una panoramica sulle funzioni di gestione} @@ -728,10 +728,10 @@ dei figli in stato di zombie: alla sua terminazione infatti tutti i suoi figli 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}} @@ -828,25 +828,27 @@ Il comportamento di \func{waitpid} pu 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}). - +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 @@ -884,18 +886,230 @@ variabile di tipo \type{int} puntata da \var{status}). 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{}}. 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{} 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{} 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 necessitano del \textit{pathname} assoluto del +programma come valore del parametro \var{path}. Le altre quattro funzioni +invece usano come parametro \var{file} un nome che viene cercato +automaticamente fra i file presenti nella lista di directory specificate dalla +variabile di ambiente \var{PATH}. + + +La terza differenza è . + + + +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. \section{Il controllo di accesso} @@ -922,10 +1136,11 @@ dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e \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 @@ -982,3 +1197,16 @@ per tener conto di eventuali \acr{suid} o \acr{sgid}. \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. + +