Die Logdateien des Systems verwalten

Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage

Online-Version

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser zur Installation & Konfiguration oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Logdateien des Systems verwalten

Das Utility syslogd schreibt verschiedene Systemaktivitäten mit, so zum Beispiel die Debugging-Meldungen von sendmail und Warnungen des Kernels. syslogd läuft als Dämon und wird in der Regel beim Booten aus einer der rc-Dateien gestartet.

Die Datei /etc/syslog.conf wird benutzt, um festzulegen, wo syslogd Informationen ablegt. Diese Datei könnte folgendermaßen aussehen:

*.info;*.notice /var/log/messages mail.debug /var/log/maillog *.warn /var/log/syslog kern.emerg /dev/console

Das erste Feld jeder Zeile bestimmt, welche Meldungen protokolliert werden sollen, und das zweite Feld gibt an, wohin die Meldungen geschrieben werden. Das erste Feld hat das Format:

Ursprung.Level [;Ursprung.Level... ]

Dabei bezeichnet der Ursprung das Systemprogramm oder die Komponente des Systems, die die Meldung verursacht, und der Level gibt an, wie schwerwiegend die Meldung ist.

Der Ursprung kann zum Beispiel mail sein (für den Mail-Dämon), kern (für den Kernel), user (für Benutzerprogramme) oder auth (für Programme, die den Zugang zum System kontrollieren, wie etwa login oder su). Ein Stern in diesem Feld steht für Meldungen aus allen Quellen.

Als Level können Sie folgendes angeben (mit zunehmender Wichtigkeit): debug, info, notice, warning, err, crit, alert oder emerg.

In der oben gezeigten Datei /etc/syslog.conf sehen wir, daß alle Meldungen der Grade info und notice in die Datei /var/adm/messages geschrieben werden, debug-Meldungen (und Meldungen höherer Stufe) des Mail-Dämons gehen nach /var/adm/maillog, und alle Meldungen der Stufe warn werden in /var/adm/syslog protokolliert. Außerdem werden die emerg-Warnungen des Kernels an die Konsole geschickt (das ist die gerade aktive virtuelle Konsole oder ein xterm-Fenster, das mit der Option -C gestartet wurde).

Die von syslogd protokollierten Meldungen enthalten in der Regel das Datum, einen Hinweis auf den Prozeß oder die Komponente, die die Meldung verursacht hat, sowie die Meldung selbst - alles in einer Zeile. Eine Nachricht des Kernels, die auf Probleme mit Daten in einem ext2fs-Dateisystem hinweist, könnte so in der Logdatei erscheinen:

Dec 1 21:03:35 loomer kernel: EXT2-fs error (device 3/2): ext2_check_blocks_bit map: Wrong free blocks count in super block, stored = 27202, counted = 27853

Ein erfolgreich ausgeführtes su könnte folgendermaßen registriert werden:

Dec 11 15:31:51 loomer su: mdw on /dev/ttyp3

Die Logdateien sind äußerst wichtig beim Aufspüren von Problemen im System. Eine zu groß gewordene Logdatei können Sie mit rm entfernen; sie wird beim nächsten Neustart von syslogd erneut angelegt.

Wahrscheinlich enthält Ihr System bereits einen syslogd und die Datei /etc/syslog.conf in einer brauchbaren Konfiguration. Trotzdem ist es wichtig, daß Sie wissen, wo Ihre Logdateien stehen und welche Programme damit verbunden sind. Falls Sie weitere Meldungen protokollieren lassen möchten (zum Beispiel Debugging-Nachrichten des Kernels, die sehr umfangreich sein können), sollten Sie die Datei syslog.conf editieren und dann den syslogd anweisen, seine Konfigurationsdatei erneut zu lesen. Geben Sie dazu ein:

kill -HUP `cat /var/run/syslog.pid`

Beachten Sie die rückwärts geneigten Anführungszeichen (Backquotes), mit denen die Prozeß-ID von syslogd aus /var/run/syslog.pid extrahiert wird.

Eventuell sind auf Ihrem System weitere Logdateien vorhanden. Darunter könnten folgende sein:

/var/log/wtmp Diese Datei enthält binäre Daten, in denen die Login-Zeiten und -Dauer aller Systembenutzer registriert sind. Der Befehl last erstellt daraus eine Liste der Logins. Diese Liste könnte zum Beispiel so aussehen: mdw tty3 Sun Dec 11 15:25 still logged in mdw tty3 Sun Dec 11 15:24 - 15:25 (00:00) mdw tty1 Sun Dec 11 11:46 still logged in reboot ~ Sun Dec 11 06:46

In der Datei /var/adm/wtmp wird auch vermerkt, wann das System neu gestartet wurde.

/var/run/utmp

Dies ist eine weitere binäre Datei, die Informationen zu den derzeit eingeloggten Benutzern enthält. Die Befehle who, w und finger erstellen daraus Login-Informationen. Der Befehl w könnte zum Beispiel folgendes ausgeben:

3:58pm up 4:12, 5 users, load average: 0.01, 0.02, 0.00 User tty login@ idle JCPU PCPU what mdw ttyp3 11:46am 14 - mdw ttyp2 11:46am 1 w mdw ttyp4 11:46am kermit mdw ttyp0 11:46am 14 bash

Icon

w (1)

Wir sehen die Login-Zeiten aller Benutzer (in diesem Fall ein Benutzer, der mehrfach eingeloggt ist) sowie den gerade ausgeführten Befehl. In der Manpage zu w finden Sie eine Beschreibung aller Felder.

/var/log/lastlog Diese Datei hat eine ähnliche Funktion wie wtmp, wird aber von anderen Programmen benutzt (zum Beispiel finger, um festzustellen, wann ein Benutzer zuletzt eingeloggt war).

Icon

Beachten Sie, daß die Dateien wtmp und utmp auf verschiedenen Systemen unterschiedliche Formate haben können. Manche Programme sind so kompiliert, daß sie das eine Format erwarten, und andere so, daß sie das andere Format erwarten. Deshalb kann es passieren, daß die Befehle, die auf diese Dateien zugreifen, verwirrende oder falsche Informationen ausgeben - dies gilt besonders dann, wenn die Dateien von einem Programm geschrieben werden, das ein falsches Format benutzt.

Logdateien können ziemlich groß werden, und wenn Sie nicht gerade gewaltige Mengen Plattenplatz zur Verfügung haben, dann müssen Sie etwas dagegen tun, daß die Logdateien Ihre Partitionen zu schnell füllen. Natürlich können Sie die Logdateien von Zeit zu Zeit löschen, aber das wollen Sie vielleicht nicht, weil diese ja schließlich auch Informationen enthalten, die in Problemfällen nützlich werden können.

Eine Möglichkeit, dieses Problem zu beheben, besteht darin, die Logdateien von Zeit zu Zeit in eine andere Datei zu kopieren und diese dann zu komprimieren. Die Logdatei selbst beginnt dann wieder bei 0. Hier ist ein kurzes Shell-Skript, das genau das für die Logdatei /var/log/messages tut:

mv /var/log/messages /var/log/messages-backup cp /dev/null /var/log/messages CURDATE=`date +"%m%d%y"` mv /var/log/messages-backup /var/log/messages-$CURDATE gzip /var/log/messages-$CURDATE

Zunächst geben wir der Logdatei einen anderen Namen und setzen die Ursprungsdatei auf 0 Bytes zurück, indem wir von /dev/null dahin kopieren. Das machen wir, damit das Logging weitergehen kann, während die nächsten Schritte durchgeführt werden. Wir berechnen einen Datumsstring, der das aktuelle Datum enthält und als Suffix für den Dateinamen verwendet wird, benennen die Backup-Datei um und komprimieren sie schließlich mit gzip.

Sie können dieses kleine Skript von cron aus ausführen, aber so, wie es hier steht, sollte es nicht mehr als einmal täglich ausgeführt werden, da sonst die komprimierte Kopie wieder überschrieben wird, denn der Dateiname enthält nur das Datum, nicht aber die Uhrzeit. Wenn Sie dieses Skript in kürzeren Intervallen benutzen wollen, müssen Sie zusätzliche Nummern verwenden, um zwischen den einzelnen Kopien zu unterscheiden.

An diesem Skript könnten noch einige Verbesserungen vorgenommen werden. Beispielsweise könnte man zunächst die Größe der Logdatei überprüfen und sie nur dann kopieren und komprimieren, wenn diese Größe eine vorbestimmte Grenze überschreitet.

Auch wenn das schon eine Verbesserung ist, wird die Partition mit den Logdateien irgendwann voll sein. Sie können dieses Problem lösen, indem Sie nur eine bestimmte Zahl von komprimierten Logdateien (zum Beispiel 10) behalten. Wenn diese Zahl erreicht ist, löschen Sie die älteste und überschreiben sie mit der nächsten zu kopierenden Logdatei. Dieses Verfahren wird auch Logrotation genannt. In manchen Distributionen gibt es Skripten wie savelog oder logrotate, um diesen Vorgang zu automatisieren.

Zum Abschluß dieses Abschnitts sollte noch gesagt werden, daß die meisten neueren Distributionen wie SuSE, Debian und Red Hat bereits mitgelieferte cron-Skripten enthalten, die Ihre Logdateien verwalten und sehr viel raffinierter sind als das kleine hier vorgestellte.

Weitere Informationen zum Linux - Wegweiser zur Installation & Konfiguration

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center