-\subsection{Prescrizioni per un programma \textit{daemon}}
+\subsection{Le prescrizioni per un \textsl{demone} ed il \textit{syslog}}
\label{sec:sess_daemon}
Come sottolineato fin da sez.~\ref{sec:intro_base_concept}, in un sistema
e delle funzionalità che sono previste; ma gli errori devono normalmente
essere notificati all'amministratore del sistema.
+\itindbeg{syslog}
+
Una soluzione può essere quella di scrivere gli eventuali messaggi su uno
specifico file (cosa che a volte viene fatta comunque) ma questo comporta il
grande svantaggio che l'amministratore dovrà tenere sotto controllo un file
diverso per ciascun demone, e che possono anche generarsi conflitti di nomi.
Per questo in BSD4.2 venne introdotto un servizio di sistema, il
-\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permettesse
-ai demoni di inviare messaggi all'amministratore in una maniera
-standardizzata.
+\textit{syslog}, che oggi si trova su tutti i sistemi Unix, e che permette ai
+demoni di inviare messaggi all'amministratore in una maniera
+standardizzata.
Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
-in un sistema unix-like, viene gestito attraverso un apposito programma,
-\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
-errore vengono raccolti dal file speciale \file{/dev/log}, un socket locale
-(vedi sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con
-un socket UDP, o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
-kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
- scritti tramite la funzione \func{printk}, analoga alla \func{printf} usata
- in user space; una trattazione eccellente dell'argomento si trova in
- \cite{LinDevDri}, nel quarto capitolo.}
-
-Il servizio permette poi di trattare i vari messaggi classificandoli
-attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
-diverse categorie i vari demoni in modo di raggruppare i messaggi provenienti
-da operazioni che hanno attinenza fra loro, ed è organizzato in sottosistemi
-(kernel, posta elettronica, demoni di stampa, ecc.). Il secondo, chiamato
-\textit{priority}, identifica l'importanza dei vari messaggi, e permette di
-classificarli e differenziare le modalità di notifica degli stessi.
-
-Il sistema di \textit{syslog} attraverso \cmd{syslogd} provvede poi a
-riportare i messaggi all'amministratore attraverso una serie differenti
-meccanismi come:
+in un sistema unix-like, viene gestito attraverso un apposito programma, che è
+anch'esso un \textsl{demone}. In generale i messaggi di errore vengono
+raccolti dal file speciale \file{/dev/log}, un socket locale (vedi
+sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con un
+socket UDP e trattati dal demone che gestisce il servizio. Il più comune di
+questi è \texttt{syslogd}, che consente un semplice smistamento dei messaggi
+sui file in base alle informazioni in esse presenti.\footnote{ad oggi però
+ \texttt{syslogd} è in sostanziale disuso, sostituito da programmi più
+ sofisticati come \texttt{rsyslog} o \texttt{syslog-ng}.}
+
+Il servizio del \textit{syslog} permette infatti di trattare i vari messaggi
+classificandoli attraverso due indici; il primo, chiamato \textit{facility},
+suddivide in diverse categorie i messaggi in modo di raggruppare quelli
+provenienti da operazioni che hanno attinenza fra loro, ed è organizzato in
+sottosistemi (kernel, posta elettronica, demoni di stampa, ecc.). Il secondo,
+chiamato \textit{priority}, identifica l'importanza dei vari messaggi, e
+permette di classificarli e differenziare le modalità di notifica degli
+stessi.
+
+Il sistema del \textit{syslog} attraverso il proprio demone di gestione
+provvede poi a riportare i messaggi all'amministratore attraverso una serie
+differenti meccanismi come:
\begin{itemize*}
\item scrivere sulla console.
\item inviare via mail ad uno specifico utente.
\item inviare ad un altro demone (anche via rete).
\item scartare.
\end{itemize*}
-secondo le modalità che questo preferisce e che possono essere impostate
-attraverso il file di configurazione \conffile{/etc/syslog.conf} (maggiori
-dettagli si possono trovare sulle pagine di manuale per questo file e per
-\cmd{syslogd}).
+le modalità dipendono ovviamente dal demone di gestione che si usa, per la
+gestione del quale si rimanda ad un testo di amministrazione di
+sistema.\footnote{l'argomento è ad esempio coperto dal capitolo 3.2.3 si
+ \cite{AGL}.}
Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
\begin{prototype}{syslog.h}{void openlog(const char *ident, int option,
int facility)}
-Apre una connessione al sistema di \textit{syslog}.
+Apre una connessione al sistema del \textit{syslog}.
\bodydesc{La funzione non restituisce nulla.}
\end{prototype}
\const{LOG\_CRON} & Messaggi dei demoni di gestione dei comandi
programmati (\cmd{cron} e \cmd{at}).\\
\const{LOG\_DAEMON} & Demoni di sistema.\\
- \const{LOG\_FTP} & Server FTP.\\
+ \const{LOG\_FTP} & Servizio FTP.\\
\const{LOG\_KERN} & Messaggi del kernel.\\
\const{LOG\_LOCAL0} & Riservato all'amministratore per uso locale.\\
- --- & \\
+ \hspace{.5cm}--- & \hspace{3cm} ...\\
\const{LOG\_LOCAL7} & Riservato all'amministratore per uso locale.\\
\const{LOG\_LPR} & Messaggi del sistema di gestione delle stampanti.\\
\const{LOG\_MAIL} & Messaggi del sistema di posta elettronica.\\
\const{LOG\_NEWS} & Messaggi del sistema di gestione delle news
(USENET).\\
- \const{LOG\_SYSLOG} & Messaggi generati dallo stesso \cmd{syslogd}.\\
+ \const{LOG\_SYSLOG} & Messaggi generati dal demone di gestione del
+ \textit{syslog}.\\
\const{LOG\_USER} & Messaggi generici a livello utente.\\
- \const{LOG\_UUCP} & Messaggi del sistema UUCP.\\
+ \const{LOG\_UUCP} & Messaggi del sistema UUCP (\textit{Unix to Unix
+ CoPy}, ormai in disuso).\\
\hline
\end{tabular}
\caption{Valori possibili per l'argomento \param{facility} di \func{openlog}.}
\textbf{Valore}& \textbf{Significato}\\
\hline
\hline
-\const{LOG\_CONS} & Scrive sulla console quando. \\
-\const{LOG\_NDELAY} & Sostituisce \const{LOG\_AUTH}.\\
-\const{LOG\_NOWAIT} & Messaggi dei demoni di gestione dei comandi
- programmati (\cmd{cron} e \cmd{at}).\\
-\const{LOG\_ODELAY} & \\
-\const{LOG\_PERROR} & Stampa anche su \file{stderr}.\\
+\const{LOG\_CONS} & Scrive sulla console in caso di errore nell'invio del
+ messaggio al sistema del \textit{syslog}. \\
+\const{LOG\_NDELAY} & Apre la connessione al sistema del \textit{syslog}
+ subito invece di attendere l'invio del primo messaggio.\\
+\const{LOG\_NOWAIT} & Non usato su Linux, su altre piattaforme non attende i
+ processi figli creati per inviare il messaggio.\\
+\const{LOG\_ODELAY} & Attende il primo messaggio per aprire la connessione al
+ sistema del \textit{syslog}.\\
+\const{LOG\_PERROR} & Stampa anche su \file{stderr} (non previsto in
+ POSIX.1-2001).\\
\const{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo
chiamante.\\
\hline
\macro{LOG\_UPTO(p)} che permette di specificare automaticamente tutte le
priorità fino ad un certo valore.
+\itindend{syslog}
+
+
+Oltre ai vari demoni, il servizio viene utilizzato anche dal kernel per
+comunicare messaggi in user space, in questo caso
+
+
+ o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
+kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
+ scritti tramite la funzione \func{printk}, analoga alla \func{printf} usata
+ in user space; una trattazione eccellente dell'argomento si trova in
+ \cite{LinDevDri}, nel quarto capitolo.}
+
\section{L'I/O su terminale}
projects / gapil.git / blobdiff