\const{LINK\_MAX} &8 & numero massimo di link a un file\\
\const{NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\
\const{PATH\_MAX}& 256 & lunghezza in byte di un
- \index{\textit{pathname}}\textit{pathname}.\\
+ \itindex{pathname}\textit{pathname}.\\
\const{PIPE\_BUF}&4096 & byte scrivibili atomicamente in una pipe
(vedi sez.~\ref{sec:ipc_pipes}).\\
\const{MAX\_CANON}&255 & dimensione di una riga di terminale in modo
\const{\_POSIX\_LINK\_MAX} &8 & numero massimo di link a un file.\\
\const{\_POSIX\_NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\
\const{\_POSIX\_PATH\_MAX}& 256 & lunghezza in byte di un
- \index{\textit{pathname}}\textit{pathname}.\\
+ \itindex{pathname}\textit{pathname}.\\
\const{\_POSIX\_PIPE\_BUF}& 512 & byte scrivibili atomicamente in una
pipe.\\
\const{\_POSIX\_MAX\_CANON}&255 & dimensione di una riga di
a quale file si fa riferimento, dato che il valore del limite cercato può
variare a seconda del filesystem. Una seconda versione della funzione,
\funcd{fpathconf}, opera su un file descriptor invece che su un
-\index{\textit{pathname}}\textit{pathname}. Il suo prototipo è:
+\itindex{pathname}\textit{pathname}. Il suo prototipo è:
\begin{prototype}{unistd.h}{long fpathconf(int fd, int name)}
Restituisce il valore del parametro \param{name} per il file \param{fd}.
\bodydesc{È identica a \func{pathconf} solo che utilizza un file descriptor
- invece di un \index{\textit{pathname}}\textit{pathname}; pertanto gli
- errori restituiti cambiano di conseguenza.}
+ invece di un \itindex{pathname}\textit{pathname}; pertanto gli errori
+ restituiti cambiano di conseguenza.}
\end{prototype}
\noindent ed il suo comportamento è identico a quello di \func{pathconf}.
occorrerà includere anche i file \file{linux/unistd.h} e
\file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un
cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene
-per la risoluzione di un \index{\textit{pathname}}\textit{pathname} (da cui
-l'uso alternativo del filesystem \file{/proc}, che vedremo dopo).
+per la risoluzione di un \itindex{pathname}\textit{pathname} (da cui l'uso
+alternativo del filesystem \file{/proc}, che vedremo dopo).
Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
arriva ad identificare un parametro specifico è passato alla funzione
In particolare l'albero dei valori di \func{sysctl} viene presentato in forma
di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
-specificando un \index{\textit{pathname}}\textit{pathname} e leggendo e
-scrivendo sul file corrispondente al parametro scelto. Il kernel si occupa di
-generare al volo il contenuto ed i nomi dei file corrispondenti, e questo ha
-il grande vantaggio di rendere accessibili i vari parametri a qualunque
-comando di shell e di permettere la navigazione dell'albero dei valori.
+specificando un \itindex{pathname}\textit{pathname} e leggendo e scrivendo sul
+file corrispondente al parametro scelto. Il kernel si occupa di generare al
+volo il contenuto ed i nomi dei file corrispondenti, e questo ha il grande
+vantaggio di rendere accessibili i vari parametri a qualunque comando di shell
+e di permettere la navigazione dell'albero dei valori.
Alcune delle corrispondenze dei file presenti in \file{/proc/sys} con i valori
di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
\textit{mount point} o di spostarlo quando \param{target} non è un
\textit{mount point} o è \file{/}.
\item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
- componenti del \index{\textit{pathname}}\textit{pathname}, o si è cercato
+ componenti del \itindex{pathname}\textit{pathname}, o si è cercato
di montare un filesystem disponibile in sola lettura senza averlo
specificato o il device \param{source} è su un filesystem montato con
l'opzione \const{MS\_NODEV}.
informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da
mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare
e memorizzare dette informazioni su supporti diversi, introducendo il sistema
-del \index{\textit{Name~Service~Switch}}\textit{Name Service Switch} che
-tratteremo brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la
-maggior parte delle sua applicazioni sono relative alla risoluzioni di nomi di
-rete.
+del \itindex{Name~Service~Switch}\textit{Name Service Switch} che tratteremo
+brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la maggior
+parte delle sua applicazioni sono relative alla risoluzioni di nomi di rete.
In questo paragrafo ci limiteremo comunque a trattere le funzioni classiche
per la lettura delle informazioni relative a utenti e gruppi tralasciando
Le funzioni viste finora sono in grado di leggere le informazioni sia
direttamente dal file delle password in \file{/etc/passwd} che tramite il
-sistema del \index{\textit{Name~Service~Switch}}\textit{Name Service Switch} e
+sistema del \itindex{Name~Service~Switch}\textit{Name Service Switch} e
sono completamente generiche. Si noti però che non c'è una funzione che
permetta di impostare direttamente una password.\footnote{in realtà questo può
essere fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che
Gli altri tre campi servono a quantificare l'uso della memoria
virtuale\index{memoria~virtuale} e corrispondono rispettivamente al numero di
-\textit{page fault}\index{\textit{page~fault}} (vedi
-sez.~\ref{sec:proc_mem_gen}) avvenuti senza richiedere I/O su disco (i
-cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O
-su disco (detti invece \textit{major page fault}) ed al numero di volte che il
-processo è stato completamente tolto dalla memoria per essere inserito nello
-swap.
+\textit{page fault}\itindex{page~fault} (vedi sez.~\ref{sec:proc_mem_gen})
+avvenuti senza richiedere I/O su disco (i cosiddetti \textit{minor page
+ fault}), a quelli che invece han richiesto I/O su disco (detti invece
+\textit{major page fault}) ed al numero di volte che il processo è stato
+completamente tolto dalla memoria per essere inserito nello swap.
In genere includere esplicitamente \file{<sys/time.h>} non è più strettamente
necessario, ma aumenta la portabilità, e serve comunque quando, come nella
\subsection{Limiti sulle risorse}
\label{sec:sys_resource_limit}
-Come accennato nell'introduzione oltre a mantenere i dati relativi all'uso
-delle risorse da parte dei vari processi, il kernel mette anche a disposizione
-delle funzioni con cui si possono imporre dei limiti sulle risorse che essi
-possono utilizzare. In generale ad ogni processo vengono associati due
-diversi limiti per ogni risorsa; questi sono detti il \textsl{limite corrente}
-(o \textit{current limit}) che esprime il valore massimo che attualmente il
-processo non può superare, ed il \textsl{limite massimo} (o \textit{maximum
- limit}) che esprime il valore massimo che può assumere il \textsl{limite
- corrente}.
+Come accennato nell'introduzione il kernel mette a disposizione delle
+funzionalita che permettono non solo di mantenere dati statistici relativi
+all'uso delle risorse, ma anche di imporre dei limiti precisi sul loro
+utilizzo da parte dei vari processi o degli utenti.
+
+Per far questo esistono una serie di risorse e ad ogni processo vengono
+associati due diversi limiti per ciascuna di esse; questi sono il
+\textsl{limite corrente} (o \textit{current limit}) che esprime un valore
+massimo che il processo non può superare ad un certo momento, ed il
+\textsl{limite massimo} (o \textit{maximum limit}) che invece esprime il
+valore massimo che può assumere il \textsl{limite corrente}. In generale il
+primo viene chiamato anche \textit{soft limit} dato che il suo valore può
+essere aumentato dal processo stesso durante l'esecuzione, ciò può però essere
+fatto solo fino al valore del secondo, che per questo viene detto \textit{hard
+ limit}.
-\begin{figure}[!htb]
+\begin{table}[htb]
\footnotesize
\centering
- \begin{minipage}[c]{15cm}
- \includestruct{listati/rlimit.h}
- \end{minipage}
- \normalsize
- \caption{La struttura \structd{rlimit} per impostare i limiti di utilizzo
- delle risorse usate da un processo.}
- \label{fig:sys_rlimit_struct}
-\end{figure}
-
-In generale il primo viene chiamato anche \textsl{limite soffice} (o
-\textit{soft limit}) dato che il suo valore può essere aumentato fino al
-valore del secondo, mentre il secondo è detto \textsl{limite duro} (o
-\textit{hard limit}), in quanto un processo normale può solo diminuirne il
-valore. Il valore di questi due limiti è mantenuto in una struttura
-\struct{rlimit}, la cui definizione è riportata in
-fig.~\ref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a
-limite corrente e limite massimo.
+ \begin{tabular}[c]{|l|p{12cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato}\\
+ \hline
+ \hline
+ \const{RLIMIT\_AS} & La dimensione massima della memoria virtuale di
+ un processo, il cosidetto \textit{Address
+ Space}, (vedi sez.~\ref{sec:proc_mem_gen}). Se
+ il limite viene superato dall'uso di funzioni
+ come \func{brk}, \func{mremap} o \func{mmap}
+ esse falliranno con un errore di
+ \errcode{ENOMEM}, mentre se il superamento viene
+ causato dalla crescita dello stack il processo
+ riceverà un segnale di \const{SIGSEGV}. \\
+ \const{RLIMIT\_CORE} & La massima dimensione per di un file di
+ \textit{core dump}\itindex{core~dump} (vedi
+ sez.~\ref{sec:sig_prog_error}) creato nella
+ terminazione di un processo; file di dimensioni
+ maggiori verranno troncati a questo valore,
+ mentre con un valore si bloccherà la creazione
+ dei \textit{core dump}\itindex{core~dump}.\\
+ \const{RLIMIT\_CPU} & Il massimo tempo di CPU (vedi
+ sez.~\ref{sec:sys_cpu_times}) che il processo può
+ usare. Il superamento del limite corrente
+ comporta l'emissione di un segnale di
+ \const{SIGXCPU} la cui azione predefinita (vedi
+ sez.~\ref{sec:sig_classification}) è terminare
+ il processo. Il superamento del limite massimo
+ comporta l'emissione di un segnale di
+ \const{SIGKILL}.\footnotemark\\
+ \const{RLIMIT\_DATA} & La massima dimensione del segmento dati di un
+ processo (vedi sez.~\ref{sec:proc_mem_layout}).
+ Il tentativo di allocare più memoria di quanto
+ indicato dal limite corrente causa il fallimento
+ della funzione di allocazione (\func{brk} o
+ \func{sbrk}) con un errore di \errcode{ENOMEM}.\\
+ \const{RLIMIT\_FSIZE} & La massima dimensione di un file che un processo
+ può creare. Se il processo cerca di scrivere
+ oltre questa dimensione riceverà un segnale di
+ \const{SIGXFSZ}, che di norma termina il
+ processo; se questo viene intercettato la
+ system call che ha causato l'errore fallirà con
+ un errore di \errcode{EFBIG}.\\
+ \const{RLIMIT\_LOCKS}& È un limite presente solo nelle prime versioni
+ del kernel 2.4 sul numero massimo di
+ \index{file!lock}\texttt{file lock} (vedi
+ sez.~\ref{sec:file_locking}) che un
+ processo poteva effettuare.\\
+ \const{RLIMIT\_MEMLOCK}& L'ammontare massimo di memoria che può essere
+ bloccata in RAM da un processo (vedi
+ sez.~\ref{sec:proc_mem_lock}). Dal kernel 2.6.9
+ questo limite comprende anche la memoria che può
+ essere bloccata da ciascun utente nell'uso della
+ memoria condivisa (vedi
+ sez.~\ref{sec:ipc_sysv_shm}) che viene
+ contabilizzata separatamente ma sulla quale
+ viene applicato questo stesso limite.\\
+ \const{RLIMIT\_NOFILE} & Il numero massimo di file che il processo può
+ aprire. L'apertura di un ulteriore file farà
+ fallire la funzione (\func{open}, \func{dup} o
+ \func{pipe}) con un errore \errcode{EMFILE}.\\
+ \const{RLIMIT\_NPROC} & Il numero massimo di processi che possono essere
+ creati sullo stesso user id real. Se il limite
+ viene raggiunto \func{fork} fallirà con un
+ \errcode{EAGAIN}.\\
+ \const{RLIMIT\_SIGPENDING}& Il numero massimo di segnali che possono
+ essere mantenuti in coda per ciascun utente,
+ considerando sia i segnali normali che real-time
+ (vedi sez.~\ref{sec:sig_real_time}). Il limite è
+ attivo solo per \func{sigqueue}, con \func{kill}
+ si potrà sempre inviare un segnale che non sia
+ già presente su una coda.\footnotemark\\
+ \const{RLIMIT\_STACK} & La massima dimensione dello stack del
+ processo. Se il processo esegue operazioni che
+ estendano lo stack oltre questa dimensione
+ riceverà un segnale di \const{SIGSEGV}.\\
+ \const{RLIMIT\_RSS} & L'ammontare massimo di pagine di memoria dato al
+ testo del processo. Il limite è solo una
+ indicazione per il kernel, qualora ci fosse un
+ surplus di memoria questa verrebbe assegnata.\\
+% TODO integrare con la roba di madvise
+ \hline
+ \end{tabular}
+ \caption{Valori possibili dell'argomento \param{resource} delle funzioni
+ \func{getrlimit} e \func{setrlimit}.}
+ \label{tab:sys_rlimit_values}
+\end{table}
-In genere il superamento di un limite comporta o l'emissione di un segnale o
-il fallimento della system call che lo ha provocato; per permettere di leggere
-e di impostare i limiti di utilizzo delle risorse da parte di un processo
-Linux prevede due funzioni, \funcd{getrlimit} e \funcd{setrlimit}, i cui
-prototipi sono:
+\footnotetext[18]{questo è quanto avviene per i kernel dalla serie 2.2 fino ad
+ oggi (la 2.6.x); altri kernel possono avere comportamenti diversi per quanto
+ avviene quando viene superato il \textit{soft limit}; perciò per avere
+ operazioni portabili è sempre opportuno intercettare \const{SIGXCPU} e
+ terminare in maniera ordinata il processo.}
+
+\footnotetext{il limite su questa risorsa è stato introdotto con il kernel
+ 2.6.8.}
+
+In generale il superamento di un limite corrente\footnote{di norma quanto
+ riportato in tab.~\ref{tab:sys_rlimit_values} fa riferimento a quanto
+ avviene al superamento del limite corrente, con l'eccesione
+ \const{RLIMIT\_CPU} in cui si ha in comportamento diverso per il superamento
+ dei due limiti.} comporta o l'emissione di un segnale o il fallimento della
+system call che lo ha provocato;\footnote{si nuovo c'è una eccezione per
+ \const{RLIMIT\_CORE} che influenza soltanto la dimensione (o l'eventuale
+ creazinone) dei file di \itindex{core~dump}\textit{core dump}.} per
+permettere di leggere e di impostare i limiti di utilizzo delle risorse da
+parte di un processo sono previste due funzioni, \funcd{getrlimit} e
+\funcd{setrlimit}, i cui prototipi sono:
\begin{functions}
\headdecl{sys/time.h}
\headdecl{sys/resource.h}
questo argomento sono elencati in tab.~\ref{tab:sys_rlimit_values}. L'acceso
(rispettivamente in lettura e scrittura) ai valori effettivi dei limiti viene
poi effettuato attraverso la struttura \struct{rlimit} puntata da
-\param{rlim}.
+\param{rlim}, la cui definizione è riportata in
+fig.~\ref{fig:sys_rlimit_struct}, ed i cui campi corrispondono appunto a
+limite corrente e limite massimo.
-\begin{table}[htb]
+
+\begin{figure}[!htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|p{12cm}|}
- \hline
- \textbf{Valore} & \textbf{Significato}\\
- \hline
- \hline
- \const{RLIMIT\_CPU} & Il massimo tempo di CPU che il processo può
- usare. Il superamento del limite comporta
- l'emissione di un segnale di \const{SIGXCPU}.\\
- \const{RLIMIT\_FSIZE} & La massima dimensione di un file che un processo
- può usare. Se il processo cerca di scrivere
- oltre questa dimensione riceverà un segnale di
- \const{SIGXFSZ}.\\
- \const{RLIMIT\_DATA} & La massima dimensione della memoria dati di un
- processo. Il tentativo di allocare più memoria
- causa il fallimento della funzione di
- allocazione. \\
- \const{RLIMIT\_STACK} & La massima dimensione dello stack del
- processo. Se il processo esegue operazioni che
- estendano lo stack oltre questa dimensione
- riceverà un segnale di \const{SIGSEGV}.\\
- \const{RLIMIT\_CORE} & La massima dimensione di un file di \textit{core
- dump} creato da un processo. Nel caso le
- dimensioni dovessero essere maggiori il file non
- verrebbe generato.\footnotemark\\
- \const{RLIMIT\_RSS} & L'ammontare massimo di memoria fisica dato al
- processo. Il limite è solo una indicazione per
- il kernel, qualora ci fosse un surplus di
- memoria questa verrebbe assegnata.\\
- \const{RLIMIT\_NPROC} & Il numero massimo di processi che possono essere
- creati sullo stesso user id. Se il limite viene
- raggiunto \func{fork} fallirà con un
- \errcode{EAGAIN}.\\
- \const{RLIMIT\_NOFILE} & Il numero massimo di file che il processo può
- aprire. L'apertura di un ulteriore file fallirà
- con un errore \errcode{EMFILE}.\\
- \const{RLIMIT\_MEMLOCK}& L'ammontare massimo di memoria che può essere
- bloccata in RAM senza
- paginazione\index{paginazione} (vedi
- sez.~\ref{sec:proc_mem_lock}).\\
- \const{RLIMIT\_AS} & La dimensione massima di tutta la memoria che il
- processo può ottenere. Se il processo tenta di
- allocarne di più funzioni come \func{brk},
- \func{malloc} o \func{mmap} falliranno. \\
- \hline
- \end{tabular}
- \caption{Valori possibili dell'argomento \param{resource} delle funzioni
- \func{getrlimit} e \func{setrlimit}.}
- \label{tab:sys_rlimit_values}
-\end{table}
+ \begin{minipage}[c]{15cm}
+ \includestruct{listati/rlimit.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{rlimit} per impostare i limiti di utilizzo
+ delle risorse usate da un processo.}
+ \label{fig:sys_rlimit_struct}
+\end{figure}
-\footnotetext{Impostare questo limite a zero è la maniera più semplice per
- evitare la creazione di \file{core} file (al proposito si veda
- sez.~\ref{sec:sig_prog_error}).}
Nello specificare un limite, oltre a fornire dei valori specifici, si può
anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso
di una risorsa; ma si ricordi che solo un processo con i privilegi di
-amministratore può innalzare un limite al di sopra del valore corrente del
-limite massimo. Si tenga conto infine che tutti i limiti vengono ereditati dal
-processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork}) e
-mantenuti per gli altri programmi eseguiti attraverso una \func{exec} (vedi
-sez.~\ref{sec:proc_exec}).
+amministratore\footnote{per essere precisi in questo caso quello che serve è
+ la \itindex{capability}\textit{capability} \const{CAP\_SYS\_RESOURCE}.} può
+innalzare un limite al di sopra del valore corrente del limite massimo ed
+usare un valore qualsiasi per entrambi i limiti. Si tenga conto infine che
+tutti i limiti vengono ereditati dal processo padre attraverso una \func{fork}
+(vedi sez.~\ref{sec:proc_fork}) e mantenuti per gli altri programmi eseguiti
+attraverso una \func{exec} (vedi sez.~\ref{sec:proc_exec}).
\subsection{Le risorse di memoria e processore}
precedenti le \acr{glibc} 2.1 implementavano questa funzione restituendo
sempre un valore statico.
+% TODO verificare meglio la faccenda di const{PAGE\_SIZE}
+
Le \acr{glibc} forniscono, come specifica estensione GNU, altre due funzioni,
\funcd{get\_phys\_pages} e \funcd{get\_avphys\_pages} che permettono di
ottenere informazioni riguardo la memoria; i loro prototipi sono:
\end{prototype}
La funzione restituisce in ciascun elemento di \param{loadavg} il numero medio
-di processi attivi sulla coda dello scheduler\index{\textit{scheduler}},
-calcolato su un diverso intervalli di tempo. Il numero di intervalli che si
-vogliono leggere è specificato da \param{nelem}, dato che nel caso di Linux il
-carico viene valutato solo su tre intervalli (corrispondenti a 1, 5 e 15
-minuti), questo è anche il massimo valore che può essere assegnato a questo
-argomento.
+di processi attivi sulla coda dello scheduler\itindex{scheduler}, calcolato su
+un diverso intervalli di tempo. Il numero di intervalli che si vogliono
+leggere è specificato da \param{nelem}, dato che nel caso di Linux il carico
+viene valutato solo su tre intervalli (corrispondenti a 1, 5 e 15 minuti),
+questo è anche il massimo valore che può essere assegnato a questo argomento.
projects / gapil.git / blobdiff