Visualizzare i log

Finora ci siamo limitati a configurare il sistema di logging in modo che salvi i suoi messaggi in alcuni file; ovviamente la maggior parte di questi  file non sono di nostro costante interesse ed andremo ad analizzarli con un semplice editor o viewer di testo in caso di necessità (vi, emacs, cat,  more o less vanno benissimo); più raramente, ad esempio mentre stiamo cercando di riprodurre una situazione di errore per comprendere un  problema, abbiamo l’esigenza di monitorare perennemente un file di log: in questo caso possiamo ricorrere alla comoda utility tail; per  esempio possiamo aprire una nuova console o XTerm e digitare il comando:

tail -f /var/log/mail.err

Grazie al quale avremo costantemente sott’occhio le ultime righe del file. Con analoghi sistemi è possibile monitorare costantemente i file che ci  forniscono informazioni sulla connessione di rete (utile mentre siamo collegati ad un canale IRC frequentato da gente non particolarmente
amichevole).

Ad esempio si può approntare uno script del genere (chiamiamolo /usr/local/sbin/slog):
#!/bin/sh tail -f /var/log/misclog.log | grep -v ‘from snoopy.mio [127.0.0.1]’
che, come si vede, evita di mostrare le righe che si riferiscono alle connessione effettuate in locale (snoopy.mio è il nome completo della mia macchina).

Questo comando può essere eseguito dentro una nuova finestra di xterm(1), magari creando un altro script (salvatelo come /usr/local/sbin/thelogger):
#!/bin/sh xterm -geometry 100×4+0+0 -ls -sl 200 -fg red -T “The LoggeR” \
-name logger -e /usr/local/sbin/slog
Oltre a questi semplici mezzi sono disponibili in rete anche programmi più o meno complessi studiati appositamente per monitorare ed  analizzare i vari log, spesso limitandosi ad un solo tipo di dati (ad esempio quelli forniti dal web server); vedere la sezione Link per trovarne alcuni  elenchi.

Altri log
Pur avendo parlato tanto, ci siamo per ora limitati a trattare i log gestiti tramite i daemon syslogd e klogd; questi sono tra i più importanti ed  interessanti ma non sono certamente i soli: nella directory /var/log troviamo infatti alcuni file il cui contenuto viene aggiornato autonomamente da determinati programmi senza passare dai suddetti daemon. Vediamone alcuni particolarmente significativi:
wtmp: un database che riporta i login e i logout di tutti gli utenti del sistema; contiene inoltre i dati relativi ai reboot. Questo file viene aggiornato da
login, init, halt e da certi getty ed è utilizzato da programmi come last(1).
utmp: informazioni su chi sta attualmente utilizzando il sistema (vedere ad esempio il comando who).
btmp: elenca i login falliti, è accessibile tramite lastb.
faillog: elenco dei login falliti, vedere il comando faillog.
lastlog: informazioni su quando i vari utenti hanno effettuato l’ultimo login; usare il comando lastlog (è usato anche per mostrare la data e ora dell’ultimo accesso ad ogni nuovo login).
Molti dei file qui descritti dipendono direttamente da login: vedere la pagina di manuale relativa e il file di configurazione /etc/login.defs.

Normalmente si troveranno in /var/log altri file ed altre sottodirectory: di solito queste sono gestite autonomamente da un singolo programma, la cui documentazione è quindi l’unico riferimento per formato ed uso dei file di log; esempi classici sono la sottodirectory apache (o httpd) che mantiene nota degli accessi al proprio web server e il file xdm-errors (o con un nome simile) gestito dal programma xdm(1x).

Perdersi nei log

Con tutti questi file nella directory /var/log che non fanno altro che accrescersi continuamente è facile immaginare di ritrovarsi in breve tempo con  una directory che occupa tantissimo spazio su disco, peraltro con dati che difficilmente ci interessano, specie quelli più vecchi di un certo tot di  tempo (che può essere un mese per messaggi particolarmente significativi, ma anche pochi giorni per i log di banali informazioni sul corretto  funzionamento del sistema).

Per ovviare a questo problema esistono una serie di tool normalmente inseriti in ogni distribuzione che si occupano  di prendere periodicamente i file di log, copiarne il contenuto in un file che verrà poi compresso per risparmiare ulteriore spazio ed infine  azzerarne la lunghezza; dopo un certo periodo di tempo gli stessi file compressi contenenti i vecchi log vengono cancellati definitivamente.

In Debian potete fare riferimento alla pagina di manuale del comando savelog mentre RedHat si appoggia a logrotate; entrambi vengono  normalmente eseguiti periodicamente tramite cron(8) e sono estremamente personalizzabili. Vedere la sezione Link, per questi ed altri
programmi simili.

Per rendere l’idea, una directory /var/log gestita da savelog e con un /etc/syslog.conf settato in maniera anche piuttosto prolissa difficilmente a  regime dovrebbe superare i pochissimi megabyte di dimensione, almeno su macchine casalinghe.

Analisi approfondita di syslog
Quello che abbiamo visto finora rappresenta quanto necessario conoscere per utilizzare in modo corretto il sistema di log; cerchiamo ora di  analizzare più da vicino il funzionamento di syslog, in modo da farci un quadro teorico più preciso. Il daemon principale di tutto il sistema è syslogd(), il cui comportamento è stabilito dal file di configurazione /etc/syslog.conf; si occupa di  raccogliere i messaggi da loggare e di scriverli nei rispettivi file (o di trasferirli ad un host remoto o visualizzarli sulla console, a seconda di come  configurato). Può essere avviato sia dai normali file di inizializzazione (rc.*, per intenderci) che da init tramite l’apposita opzione -n, anche se il  primo metodo è certamente il più diffuso e preferibile. Una volta lanciato di default apre in lettura la unix domain socket /dev/log dove i programmi interessati potranno inviare, tramite opportune  funzioni di libreria, i propri messaggi da far loggare; se avviato con l’opzione -r (e con permessi di superutente) si metterà anche in ascolto sulla  porta UDP 514 in modo che altre macchine possano inviargli i propri log.

Se syslogd è in grado di ricevere i messaggi provenienti dai normali programmi, va ricordato che esiste un’altra fonte importantissima di log: il  kernel. Per questo esiste il daemon klogd che può essere lanciato nel medesimo modo di syslogd (per la precisione è bene lanciare klogd  dopo di syslogd, e disattivarli in ordine inverso).
Il kernel utilizza la funzione printk() per inviare i propri messaggi: se nessuno li intercetta di default essi vengono stampati sulla console. Il  daemon klogd si pone in “ascolto” del file /proc/kmsg (il filesystem /proc è un filesystem virtuale: i suoi file non occupano spazio su disco), se  questo file non è presente o klogd viene avviato con l’opzione -s viene utilizzata l’equivalente chiamata di sistema sys_syslog().
Il formato di default dei messaggi provenienti dal kernel è:

<[0-7]>Testo del messaggio.
Dove il numero tra 0 e 7 racchiuso dalla coppia di minore/maggiore indica la priorità del messaggio; queste priorità sono definite nel file  include/linux/kernel.h (tra i sorgenti del kernel) e sono del tutto analoghe a quelle già viste per syslogd, con <7> ad indicare i messaggi di debug e  <0> per riportare che il sistema è in uno stato inutilizzabile. A questo punto quando klogd intercetta un messaggio proveniente dal kernel di default lo passa a syslogd con kern come facility e il  corrispondente livello di priorità; in alternativa klogd può essere lanciato con l’opzione -f file grazie alla quale i messaggi verranno loggati nel file  indicato.

Oltre a ciò i messaggi il cui livello sia inferiore a quello prestabilito (il default è il livello 6, quindi tutti i messaggi dei livelli da 0 a 5) vengono anche  mostrati in console; questo comportamento può essere modificato con l’opzione -c numero che consente di cambiare questa impostazione; ad  esempio può essere una buona idea usare -c 4, specie su macchine con parecchi utenti in modo da limitare i messaggi visualizzati in console a  quelli di emergenza, di allerta, critici e di errore. Come c’era da aspettarsi il kernel può trovarsi nella condizione di dover comunicare informazioni parecchio importanti, quando si trova in  situazioni critiche. In caso di serio errore interno viene generato un Oops che mostra lo stato dei registri, il contenuto della stack del kernel e il  codice che si stava eseguendo quando è intervenuto il problema.

Sfortunatamente i dati mostrati sono di norma prettamente numerici e quindi  praticamente inutili: anche se li passaste ad uno sviluppatore questi non saprebbe cosa farsene visto che questi valori variano a seconda di come il kernel è stato compilato; per ovviare a questo problema in fase di compilazione del kernel viene creato un file di nome System.map che  mappa funzioni e variabili del kernel facendo corrispondere ai loro indirizzi numerici un nome significativo. Il daemon klogd cerca questo file nell’ordine in /boot/System.map, /System.map e /usr/src/linux/System.map (oppure si può indicare quale file usare da riga di comando con  l’opzione -k file); se non lo trova dovrete manualmente utilizzare l’utility ksymoops che trovate nella directory scripts/ksymoops tra i sorgenti del kernel per tradurre i valori numerici; di norma troverete l’oops tra i file di log, ma non è però così raro trovarsi nella situazione in cui il general  protection fault sia talmente grave da uccidere klogd o impedire la scrittura su disco fisso: in questo caso è necessario trascrivere su carta  quanto mostrato sullo schermo.

A complicare ulteriormente le cose va ricordato che ormai moltissime parti del kernel possono essere compilate come moduli da caricare  dinamicamente in memoria quando necessario; in questa situazione non è possibile stabilire una corrispondenza statica tra indirizzi numerici e rappresentazione simbolica. Il kernel supporta delle chiamate di sistema utili per determinare quali moduli siano attualmente caricati in memoria;  usando queste chiamate klogd è in grado quanto meno di indicare quale modulo abbia generato l’errore (se questo è stato ben progettato  esportando le symbol information saranno disponibili maggiori dettagli); queste informazioni vanno però raccolte ed aggiornate ogni volta che un  modulo viene caricato o scaricato: klogd può venir avvertito che è richiesto un aggiornamento alle sue tabelle semplicemente chiamandolo con  l’opzione -i (usando -I si aggiornano sia le informazioni riguardanti i moduli sia quelle relative del file System.map).

Altra opzione utile in questi  casi è -p, da usare al lancio di klogd per fare in modo che le informazioni sui moduli vengano automaticamente aggiornate in caso si riceva un  oops (ovviamente questa opzione va usata con cognizione di causa: un kernel che ha sollevato un general protection fault è in una condizione  piuttosto instabile: per ricaricare le informazioni klogd ha bisogno di effettuare alcune chiamate di sistema che potrebbero compromettere l’intera  operazione e quel che resta del sistema).

In generale è preferibile fare in modo che queste informazioni siano aggiornate al caricamento e scaricamento dei moduli; per rendere la cosa  automatica (senza dover richiamare ogni volta klogd con l’opzione -i) è possibile applicare ai programmi insmod(1), rmmod(1) e modprobe del  pacchetto modules (o modutils) una patch5 che si trova tra i sorgenti di syslog; sfortunatamente questa patch è scritta per una versione non  proprio recente delle modutils, comunque leggendola non dovrebbe essere difficile capire cosa e come modificare.

Tanto syslogd quanto klogd rispondono ad una serie di segnali (che l’utente può inviare tramite il comando kill(); nella documentazione si trova l’elenco completo, qui ricordiamo solo i principali: tramite SIGHUP è possibile far rileggere il file di configurazione a syslogd, grazie a SIGTSTP e
SIGCONT è possibile rispettivamente sospendere temporaneamente e far riprendere l’esecuzione di klogd; sempre per quanto riguarda klogd si  può forzarlo ad aggiornare le informazioni relative ai moduli con il segnale SIGUSR1. Entrambi i daemon utilizzano dei file nella directory /var/run per indicare i propri PID: i file sono syslogd.pid e klogd.pid.