From: Simone Piccardi Date: Sat, 7 Sep 2002 22:42:01 +0000 (+0000) Subject: risistemato il capitolo sulle sessioni di lavoro X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=b7117ca455af39e662610dae3413cc561df91c96;p=gapil.git risistemato il capitolo sulle sessioni di lavoro --- diff --git a/session.tex b/session.tex index d3a0e4f..cdc5573 100644 --- a/session.tex +++ b/session.tex @@ -1,39 +1,105 @@ \chapter{Sessioni di lavoro} \label{cha:session} -Esamineremo in questo capitolo le modalità in cui sono organizzati i processi -all'interno del sistema e le varie relazioni che intercorrono fra di essi, e -le modalità che permettono, a partire dall'avvio del sistema, di organizzare -il lavoro degli utenti in sessioni di lavoro associate ai terminali di -controllo con cui essi si sono collegati al sistema. +Unix nasce prima dell'esistenza dei moderni PC, quando i computer occupavano +stanze intere e ci si poteva collegare solo attraverso dei terminali, ma fin +dalle sue origini è sempre stato un sistema multitasking e multiutente, +in grado di consentire l'utilizzo di un solo computer da parte di più persone. -\section{La procedura di login} +Esamineremo in questo capitolo i concetti base del sistema delle sessioni di +lavoro, vale a dire il metodo con cui il kernel gestisce l'accesso concorrente +al sistema da parte di più utenti, permettendo loro di eseguire più programmi +in contemporanea. + + +\section{Il \textit{Job control}} +\label{sec:sess_job_control} + +Viene comunemente chiamato \textit{Job control} quell'insieme di funzionalità +del sistema il cui scopo è quello di permettere ad un utente di poter +sfruttare le capacità multitasking di un sistema Unix per eseguire in +contemporanea più processi, pur potendo accedere, di solito, ad un solo +terminale,\footnote{con X e con i terminali vituali tutto questo non è più + vero, dato che si può accedere a molti terminali in contemporanea, ma il + sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto +in cui si può avere accesso all'input ed all'output degli stessi. + + +\subsection{La struttura di base} +\label{sec:sess_relation} + +Per poter gestire il \textit{Job Control} il kernel associa a ciascun processo +due ulteriori identificatori (oltre quelli visti in \secref{sec:proc_pid}): +l'identificatore del cosiddetto \textit{process group} (o +\textsl{ragguppamento di processi}), cui si fa di norma riferimento con la +sigla \acr{pgid}, l'identificatore di sessione (il \textit{session id}) cui si +fa riferimento con la sigla \acr{sid}). In questo modo, sulla base dei valori +dei rispettivi indicatori, i processi vengono organizzati in \textsl{sessioni} +e \textsl{raggruppamenti}. + +Entrambi gli identificatori vengono impostati alla creazione di ciascun +processo allo stesso valore che hanno nel processo padre, un processo appena +creato cioè appartiene sempre allo stesso raggruppamento e alla stessa +sessione del padre. La differenza fra i due identificatori è che un processo +può cambiare \acr{pgid} soltanto ad un valore che corrisponda al +\textit{process group} di un altro processo della stessa sessione, oppure al +suo stesso \acr{pid} (creando così un nuovo \textit{process group}). Se invece +si modifica il \acr{sid} il processo viene automaticamente messo anche in un +nuovo \textit{process group}, corrispondente al suo \acr{pid}. + +Per capire meglio il significato di questi identificatori vediamone subito +l'uso concreto nella gestione del \textit{job control} della linea di comando. +Una volta che si è completata la procedura di login (che esamineremo in +dettaglio in \secref{sec:sess_login}), si avrà a disposizione una shell, +associata ad un terminale (detto \textsl{terminale di controllo}), dalla quale +eseguire i comandi, una delle caratteristiche della shell è quella di +consentire di inviare un comando in \textit{background}, cioè di farlo +eseguire distaccandolo dal terminale, che potrà essere utilizzato da altri +comandi. Così un solo un comando alla volta potrà leggere e scrivere sul +terminale (quello che viene detto in \textit{foreground}). + +Fra le funzionalità della shell c'è anche quella di consentire di concatenare +più programmi in una sola riga di comando con le pipe, in tal caso, ed +inoltre, anche quando si invoca un singolo programma, questo può sempre +lanciare ulteriori sottoprocessi per eseguire dei compiti specifici. + +La shell farà si che tutti i processi che originano da un sola riga di +comando vengano raggruppati in un unico \textit{process group}; questo perché +i segnali inviati sul terminale con i comandi da tastiera (quelli illustrati +in \secref{sec:sig_job_control}) vengono inviati a tutti i processi che fan +parte del raggruppamento di \textit{foreground}, cioè quelli che stanno corre + + +Per consentire l'utilizzo contemporaneo dello stesso terminale la shell deve +essere in grado di garantire che solo un comando alla volta possa accedervi; + + + + + +Lo stato del sistema può essere verificato con il comando \cmd{ps -je f} + + + +\subsection{Il login ed il terminale di controllo} \label{sec:sess_login} -L'organizzazione del sistema del \textit{Job Control}\footnote{viene - usualmente chiamata così la capacità del sistema di poter gestire più - processi (i \textit{job}) lanciati in contemporanea a partire da una shell, - di solito associata al terminale su cui si è appunto effettuato il login, in - modo da poter gestire la possibile presenza di più di un processo che - necessita di accedere a quest'ultimo.} è strettamente connessa alle modalità -con cui un utente accede al sistema, collegandosi ad esso con un terminale, -che sia questo realmente tale, come un VT100 collegato ad una seriale o -virtuale, come quelli associati a schermo e tastiera, o semplicemente -associato ad una connessione di rete. Per questo motivo in questa prima -sezione prenderemo in esame le modalità di come avviene tutto ciò e di come il -sistema (a partire da \cmd{init}) sia in grado di gestire il tutto. - - -\subsection{Il login su terminale} -\label{sec:sess_tty_log} - -La modalità più classica di accesso ad un sistema Unix è quella del login su -terminale, che pertanto esamineremo per prima. Abbiamo già brevemente -illustrato in \secref{sec:intro_kern_and_sys} le modalità con cui il sistema -si avvia, e di come, a partire da \cmd{init}, vengano lanciati tutti gli altri -programmi. Adesso prenderemo in esame in maniera dettagliata le modalità con -cui si arriva a fornire ad un utente la shell che gli permette di lanciare i -suoi comandi. +L'organizzazione del sistema del \textit{Job Control} è strettamente connessa +alle modalità con cui un utente accede al sistema, collegandosi ad esso con un +terminale, che sia questo realmente tale, come un VT100 collegato ad una +seriale o virtuale, come quelli associati a schermo e tastiera o ad una +connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla +fine le differenze sono\footnote{in generale nel caso di login via rete o di + terminali lanciati dall'interfaccia grafica cambia anche il processo da cui + ha origine l'esecuzione della shell.} nel device cui il kernel associa i +file standard di \secref{sec:file_std_descr}, tratteremo solo il caso in +questo è il classico terminale. + +Abbiamo già brevemente illustrato in \secref{sec:intro_kern_and_sys} le +modalità con cui il sistema si avvia, e di come, a partire da \cmd{init}, +vengano lanciati tutti gli altri processi. Adesso vedremo in maniera più +dettagliata le modalità con cui il sistema arriva a fornire ad un utente la +shell che gli permette di lanciare i suoi comandi su un terminale. Nella maggior parte delle distribuzioni di GNU/Linux\footnote{fa eccezione la distribuzione \textit{Slackware}, come alcune distribuzioni su dischetto, ed @@ -44,8 +110,8 @@ lanciati, ed in quali modalit anch'esso definito nello stesso file. Tralasciando la descrizione del sistema dei run level, (per il quale si -rimanda alla lettura della pagina di manuale di \cmd{init} e di -\file{inittab}) quello che comunque viene sempre fatto è di lanciare almeno +rimanda alla lettura delle pagine di manuale di \cmd{init} e di +\file{inittab}) quello che comunque viene sempre fatto è di eseguire almeno una istanza di un programma che permetta l'accesso ad un terminale. Uno schema di massima della procedura è riportato in \secref{fig:sess_term_login}. @@ -58,12 +124,13 @@ di massima della procedura Un terminale, che esso sia un terminale effettivo, attaccato ad una seriale o ad un altro tipo di porta di comunicazione, o una delle console virtuali -associate allo schermo, viene sempre visto attraverso attraverso un device +associate allo schermo, viene sempre visto attraverso attraverso un device driver che ne presenta un'interfaccia comune su un apposito file di dispositivo. Storicamente i primi terminali erano appunto terminali di telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia, \textit{tty}, che quello dei relativi file di dispositivo, che sono sempre -della forma \texttt{/dev/tty*}. +della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali + associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.} Per controllare i terminali si usa di solito il programma \cmd{getty} (od una delle sue varianti), che permette di mettersi in ascolto sugli stessi. Alla @@ -127,73 +194,6 @@ ricevendo un \macro{SIGCHLD} all'uscita della shell, a rilanciare \cmd{getty} per ripetere da capo tutto il procedimento. -\subsection{Il login via rete} -\label{sec:sess_net_log} - -Nel caso di un login via rete la cosa si fa leggermente diversa, in tal caso -infatti non esiste un terminale fisico che \cmd{init} può tenere sotto -controllo diretto, in quanto il collegamento deve avvenire tramite la rete. -Quello che succede in questo caso è che nel procedimento di avvio del sistema -si occupa di eseguire tutti i programmi che attivano la connesione di rete, -per poi avviare tutti i programmi di servizio. - -Questo viene in genere fatto attraverso una serie di script di shell, che -vengono eseguiti in un preciso ordine (di nuovo la struttura del procedimento -di avvio di System V va al di là di quanto ci interessa trattare) che -eseguiranno i programmi richiesti, fra i quali sarà compreso (se -l'amministratore lo avrà previsto) pure il server per le connessioni di rete. - -Quest'ultimo sarà posto in esecuzione e si metterà in ascolto di eventuali -connessioni sulla rete, una volta che la procedura di avvio sarà completata -gli script termineranno ed il server si troverà ad avere \cmd{init} come -processo padre. - - -\subsection{Il login attraverso X} -\label{sec:sess_X_log} - -Quanto scritto finora riguardo i terminali è piuttosto diverso quando si ha a -che fare con X. In tal caso infatti la procedura grafica per il login è -gestira da un apposito programma (il cosiddetto \textit{Display Manager}, come -\cmd{xdm}, che fa parte della distribuzione base di X o uno dei suoi molti -cloni) che viene lanciato all'avvio insieme agli altri demoni, e che si cura -di gestire la procedura di login, lanciare eventuali programmi che si vogliono -attivare all'avvio (sia fondamentali, come il gestore delle fineste, che -effimeri, come un notificatore di posta in arrivo). - -In questo caso - - - -\section{Il \textit{Job control}} -\label{sec:sess_job_control} - -Lo scopo del \textit{Job control} è quello di permettere ad un utente di poter -sfruttare le capacità multitasking di un sistema Unix per eseguire in -contemporanea più processi, pur potendo accedere, di solito, ad un solo -terminale,\footnote{con X e con i terminali vituali tutto questo non è più - vero, dato che si può accedere a molti terminali in contemporanea, ma il - sistema è nato prima dell'esistenza di tutto ciò.} avendo cioè un solo punto -in cui si può avere accesso all'input ed all'output degli stessi. - - - -\subsection{La struttura di base} -\label{sec:sess_relation} - -Una volta che si è completata la procedura di login illustrata in -\ref{sec:sess_login} si avrà a disposizione una shell dalla quale eseguire i -comandi. Come illustrato in \secref{sec:intro_kern_and_sys} in un sistema Unix -questi non sono altro che programmi come gli altri, inoltre essendo il sistema -multitasking, non è neanche detto che un programma venga eseguito da un solo -processo, infatti, oltre all'uso delle pipe, che permette di concatenare più -con un solo comando, ed i sigoli programmi possono anche creare ulteriori -sottoprocessi per eseguire alcuni compiti. - -Tutti questi processi, che originano da un solo comando iniziale, vengono -raggruppati in quello che viene chiamato un \textit{process group}; quando -viene creato ogni -processo viene infatti mantenuto, \subsection{I \textit{process group}} @@ -215,6 +215,7 @@ processo viene infatti mantenuto, \label{sec:sess_shell} + %%% Local Variables: %%% mode: latex %%% TeX-master: "gapil" diff --git a/signal.tex b/signal.tex index 801e6ff..14e6d51 100644 --- a/signal.tex +++ b/signal.tex @@ -617,8 +617,9 @@ cui si trattano gli argomenti relativi. Questi segnali sono: gestori per far si che un programma produca una qualche azione speciale se viene fermato e riavviato, come per esempio riscrivere un prompt, o inviare un avviso. -\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta in uno stato di - sleep); il segnale non può essere né intercettato, né ignorato, né bloccato. +\item[\macro{SIGSTOP}] Il segnale ferma un processo (lo porta cioè in uno + stato di sleep, vedi \secref{sec:proc_sched}); il segnale non può essere né + intercettato, né ignorato, né bloccato. \item[\macro{SIGTSTP}] Il nome sta per \textit{interactive stop}. Il segnale ferma il processo interattivamente, ed è generato dal carattere SUSP (prodotto dalla combinazione \macro{C-z}), ed al contrario di