claim.gif
Linux Magazin Linux User Easy Linux Ubuntu User International Linux Community
Erschienen in EasyLinux 02/2005   »   Ausgabe bestellen

Protokolldateien lesen und verstehen

Lesen macht schlau

von Marcel Hilzinger


Systemprotokolle erfüllen eine wichtige Aufgabe bei der Fehlersuche und -analyse. Ihre Inhalte sind jedoch oft schwer zu entziffern. Dieser Artikel stellt Ihnen die wichtigsten Protokolldateien vor und zeigt, wie Sie daraus schlau werden.

Mit jedem Tag, den Sie am Rechner verbringen schreibt Linux ein paar Zeilen mehr in die Log-Dateien Ihres Rechners. Verantwortlich dafür sind die Programme klogd und syslogd. Bei ersterem handelt es sich um den Kernel-Logdaemon. Er führt Protokoll über die Meldungen des Betriebsystem-Kerns. Der Syslog-Daemon ist der Haupt-Protokollführer von Linux. Fast jedes Programm, das irgendwelche Meldungen protokollieren will, benutzt dazu den Syslog-Daemon. Damit aus den vielen Meldungen aber nicht eine unüberschaubare Riesendatei entsteht, arbeiten der Kernel- und der Syslogdaemon nach einem ausgeklügelten System zusammen.

Will ein Programm ein Ereignis festhalten, muss es dem Syslog-Daemon mitteilen, welche Wichtigkeit die Meldung aufweist (betrifft sie zum Beispiel nur das Programm selbst, oder auch andere Programme, ist ein schwerwiegender Fehler aufgetreten, etc.). Der Syslog-Daemon schreibt dann die Meldung je nach Kritikeitsgrad in die entsprechende Protokolldatei oder er sendet sie an einen entfernten Rechner. Letzteres ist vor allem für sicherheitsrelevante Meldungen wichtig. Stellt ein Programm zum Beispiel einen Einbruch in ein Netzwerk fest, kann es diese Meldung über den Syslog-Daemon an einen entfernten Rechner senden. Dem Angreifer fällt es dann schwerer, seine Spuren zu verwischen, da er dazu auch in den entfernten Rechner eindringen müsste. Firmen, bei denen die Sicherheit absolute Priorität genießt, drucken oft auch alle Meldungen gleich aus.

Meine Logdateien

Auch wenn auf Ihrem Rechner (hoffentlich) nichts Außergewöhnliches passiert, führt der Syslog-Daemon fortlaufend Protokoll. Seine Meldungen legt er in der Regel im Verzeichnis /var/log/ ab. Öffnen Sie das Verzeichnis in Konqueror, stellen Sie fest, dass Sie für etliche Dateien keine Leseberechtigung haben. Da einige Logdateien auch kritische Informationen enthalten (zum Beispiel Passwörter), darf diese nur der Benutzer root lesen. Eine Übersicht über die Haupt-Protokolldateien finden Sie in Tabelle 1. Unter Suse Linux führt auch YaST ein detailliertes Protokoll. Mehr dazu steht in Kasten "YaST-Protokolle".

Eine der wichtigsten Protokolldateien -- quasi das Hauptprotokoll -- stellt /var/log/messages dar. In dieser Datei befindet sich eine Sammlung relevanter Meldungen, beginnend bei Netzwerkfehlern über Anmeldeinformationen bis zu Hardware-Meldungen. Mandrake Linux führt dazu auch noch die Datei /var/log/syslog. Im Optimalfall stehen in der Datei viele Zeilen mit dem Eintrag -- MARK --. Diese Zeilen schreibt der Syslog in die Logdatei, wenn für 20 Minuten nichts bemerkenswertes los war. Grund zur Besorgnis besteht aber auch dann nicht, wenn Sie keine Mark-Einträge in der Protokolldatei finden. Bei regelmäßigem Arbeiten mit Ihrem Linux-Rechner, geschieht fast immer etwas, das dem Syslog Grund zu einem Eintrag gibt.

Um /var/log/messages unter KDE zu betrachten starten Sie mit [Alt-F2] und der Eingabe von kdesu kate den Editor Kate. Hier öffnen Sie dann die Datei wie gewohnt über Datei / Öffnen. Unter Suse Linux können Sie auch mit [Strg-Alt-F10] auf die zehnte Konsole wechseln, um das Systemprotokoll mitzulesen. Anschließend kehren Sie mit [Strg-Alt-F7] wieder zur grafischen Oberfläche zurück.

Tabelle 1: Wichtige Protokolldateien
DateiFunktion
/var/log/messagesHauptprotokolldatei des Systems (Fedora Core, Suse Linux)
/var/log/syslogHauptprotokolldatei (Mandrake Linux)
/var/log/boot.*Systemmeldungen während des Bootvorganges
/var/log/XFree86.0.logProtokolldatei des X-Servers
/var/log/wtmpProtokolldatei über die Anmeldevorgänge
/var/log/YaST2/Logdateien von YaST
/root/drakx/Logdateien von Drakconf
/var/log/yum.logLogdatei des Fedora Paketmanagers

Live-Übertragung

Die Messages-Datei protokolliert auch Informationen über angeschlossene Hardware-Elemente, wie USB-Speicher, Digitalkameras, Drucker oder Scanner. Hier lohnt es sich oft, die Meldungen in der Datei live mitzuverfolgen. Öffnen Sie dazu über [Alt-F2] und die Eingabe von konsole das KDE-Terminal. Danach wechseln Sie mit su und anschließender Passworteingabe zum Benutzer root, und geben folgenden Befehl ein:

tail -f /var/log/messages

Haben Sie zuhause ein USB-Gerät, schließen Sie es jetzt an den Rechner an und schalten es ein. Sie sollten daraufhin einige Meldungen im KDE-Terminalfenster sehen. Da USB-Memorysticks und digitale Fotoapparate zu den am weitesten verbreiteten Periferiegeräten gehören, analysiert dieser Artikel jetzt kurz eine entsprechende Ausgabe (siehe Kasten "USB-Memorystick Protokoll"). Die Meldungen erzeugte Suse Linux 9.1 beim Anschließen eines Memorysticks.

Alle Zeilen beginnen mit dem aktuellen Datum, der Uhrzeit und dem Rechnernamen (kim). In der nächsten Spalte steht, von wem die Meldung stammt. Die ersten vier Zeilen stammen vom Kernel. Er hat ein neues USB-Gerät gefunden und zeigt das entsprechende Produkt mit Hersteller und Seriennummer an. Diese Informationen sind je nach Gerät mehr oder weniger detailliet. Die Ausführlichkeit der Informationen hat aber in der Regel keinen direkten Einfluss auf die Funktionalität der Hardware.

In Zeile fünf meldet sich der USB-Hotplug-Agent zu Wort. Hotplug ist ein System für das automatische Einrichten von Hardware-Elementen, die sich beliebig ein und ausschalten lassen. Es wird von allen EasyLinux-Distributionen verwendet. Hotplug beklagt in diesem Beispiel, dass es kein entsprechendes Gerät findet, da der Kernel den entsprechenden Treiber noch nicht geladen hat. In den Zeilen sechs bis 18 holt der Kernel dies nach. Er lädt den Gerätetreiber (in diesem Fall das usb_storage-Modul) und meldet anschließend, dass jetzt ein USB-Massenspeichergerät zur Verfügung steht (USB Mass Storage support registered). Eine der wichtigsten Informationen steht in Zeile 13. Hier meldet der Kernel, dass es sich um das Gerät /dev/sda handelt, auf dem sich eine Partition (/dev/sda1) befindet.

Ab Zeile 19 kommt erneut ein Hotplug-Agent zum Zug. Dieses Mal ist es der Blockgeräte-Agent. Er bemerkt das neue Gerät und mountet es automatisch nach /media/usb-storage-0000610428724B12:0:0:0p1 (letzte Zeile).

USB-Memorystick Protokoll

Dec 10 16:53:27 kim kernel: usb 1-1: new full speed USB device using address 2
Dec 10 16:53:27 kim kernel: usb 1-1: Product: <USB PRODUCT>
Dec 10 16:53:27 kim kernel: usb 1-1: Manufacturer: <USB MF>
Dec 10 16:53:27 kim kernel: usb 1-1: SerialNumber: 0000610428724B12
Dec 10 16:53:27 kim /etc/hotplug/usb.agent[3317]: need a device for this command
Dec 10 16:53:33 kim kernel: Initializing USB Mass Storage driver...
Dec 10 16:53:33 kim kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Dec 10 16:53:33 kim kernel:   Vendor: Medion    Model: MD-551X           Rev: 0100
Dec 10 16:53:33 kim kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Dec 10 16:53:33 kim kernel: SCSI device sda: 250624 512-byte hdwr sectors (128 MB)
Dec 10 16:53:33 kim kernel: sda: assuming Write Enabled
Dec 10 16:53:33 kim kernel: sda: assuming drive cache: write through
Dec 10 16:53:33 kim kernel:  sda: sda1
Dec 10 16:53:33 kim kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
Dec 10 16:53:33 kim kernel: Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0
Dec 10 16:53:33 kim kernel: USB Mass Storage device found at 2
Dec 10 16:53:33 kim kernel: usbcore: registered new driver usb-storage
Dec 10 16:53:33 kim kernel: USB Mass Storage support registered.
Dec 10 16:53:34 kim /etc/hotplug/block.agent[3410]: new block device /block/sda
Dec 10 16:53:34 kim /etc/hotplug/block.agent[3419]: waiting for /var/lock/block.agent.lock, process 3410 holds it
Dec 10 16:53:39 kim /etc/hotplug/block.agent[3419]: new block device /block/sda/sda1
Dec 10 16:53:44 kim /etc/hotplug/block.agent[3419]: mount by-path/usb-storage-0000610428724B12:0:0:0p1

Fehleranalyse

Funktioniert bei Ihrer Distribution etwas nicht, hilft Ihnen die Protokolldatei, die wichtigsten Information herauszufiltern. So kennt zum Beispiel Feodra Core 2 noch keinen Automounter. Sie müssen hier die Partition /dev/sda1 von Hand einhängen. Bleiben bei Ihrem Gerät die Meldungen nach dem USB-Agent (Zeile 7) aus, ist vermutlich das automatische Laden des usb_storage-Modules fehlgeschlagen. In diesem Fall geben Sie als root den Befehl

modprobe usb_storage

ein, und schließen dann das Gerät nochmals an. Gerade bei USB-Geräten kommt es auch oft vor, dass die entsprechende Hardware nur dann funktioniert, wenn Sie sie bereits vor dem Hochfahren des Systems anschließen. Andere Geräte funktionieren wiederum nur, wenn Sie während des Bootprozesses nicht eingesteckt sind. Bei derartigen Problemen finden Sie in den Systemmeldungen zum Bootprozess, dem so genannten Startprotokoll, wichtige Hinweise. Auch diese Datei befindet sich im Verzeichnis /var/log und hört unter Suse Linux auf den Namen boot.msg. Bei Fedora Core heißt sie boot.log und unter Mandrake Linux dmesg. Obschon sich der Inhalt des Startprotokolls als Benutzer mit dem Befehl

/bin/dmesg | less

lesen lässt, empfiehl es sich, die Datei wie oben beschrieben als root mit dem Editor Kate zu öffnen. Suse Linux bietet für die Einsicht in die verschiedenen Logdateien auch zwei YaST-Module an (siehe Abbildung 1). Sie starten sie über Verschiedenes / Startprotokoll anzeigen respektive Verschiedenes / Systemprotokoll anzeigen, dann wählen Sie aus der Aufklappliste die entsprechende Datei aus. Eine Suchfunktion beinhalten die Module jedoch nicht, so dass Sie auch hier besser den Editor benutzen.

YaST-Protokolle

Unter /var/log/YaST2/ finden Benutzer von Suse Linux mehrere Logdateien. In der Hauptdatei y2log hält YaST sämtliche Einstellungen fest. In den Dateien y2log-1 bis y2log-9 speichet das Programm Informationen zu den einzelnen Modulen. Diese Logdateien sind allerdings in erster Linie für YaST-Entwickler interessant.

Hilfreich im täglichen Gebrauch erweisen sich eventuell folgende Dateien:

  • y2logRPM
  • badlist
  • y2log.SuSEconfig

In der ersten Datei hält YaST die Installation von RPM-Paketen fest, inklusive der Erstinstallation. Sie ist hilfreich, wenn Sie zum Beispiel nach dem Einspielen von 30 Paketen nicht mehr wissen, was Sie soeben installiert haben. Ein Blick in die Datei hilft auch, wenn Programme nach einem Software-Update nicht mehr funktionieren. Sie können sich dann die installierten Pakete notieren und diese löschen oder wieder von den Original-Medien einspielen.

Die Datei badlist enthält Informationen über nicht erfüllte Paketabhängigkeiten. YaST zeigt diese beim Starten des Software-Modules an, solange Sie nicht auf Alle ignorieren klicken. Haben Sie dies aus Versehen getan, lesen Sie hier, welche Pakete Schwierigkeiten bereiten.

In y2log.SuSEconfig schließlich finden Sie die Meldungen, die YaST beim Ausführen von SuSEconfig auf dem Bildschirm ausgiebt. Diese Meldungen sind je nach Geschwindigkeit des Rechners oft nur kurz zu lesen. Hier lassen sie sich in aller Ruhe studieren.

Abb. 1: Suse Linux bietet zum Betrachten der Hauptprotokolldateien zwei YaST-Module an.

Das Startprotokoll beinhaltet alle Meldungen, die beim Hochfahren des Systems am Bildschirm erscheinen. Normalerweise steht jede Zeile für eine bestimmte Aufgabe. Am Ende der Zeile steht dann, ob der Kernel die Aufagbe erfüllen konnte (Done, OK oder Succeeded) oder ob dabei Fehler auftraten (Failed). Bereitet Ihnen zum Beispiel ein USB-Gerät Schwierigkeiten, suchen Sie im Editor über [Strg-F] nach USB (Groß- und Kleinschreibung prüfen). Sie sollten dann einen Eintrag finden, der auf den Start den USB-Systems hindeutet. Alternativ suchen Sie gleich nach dem Stichwort Failed. Findet der Editor keinen Treffer, liegt das Problem an einer anderen Stelle. Hatten Sie bei Ihrer Suche Erfolg, notieren Sie sich, wann das Protokoll erstellt wurde. Klicken Sie dazu in Konqueror mit der rechten Maustaste auf die Datei und wählen Sie Eigenschaften. Hier finden Sie das Datum und die genaue Uhrzeit unter Geändert. Dann schauen Sie in /var/log/messages nach, welche Meldungen der Syslogd zu dieser Zeit im Systemprotokoll festhielt.

In sehr seltenen Fällen kommt es auch vor, dass das System auf Grund einer Hardwarekomponente überhaupt nicht startet. In diesem Fall nützt es natürlich nichts, in boot.msg nach Fehlern zu suchen, da die Datei ja nur das aktuelle Startprotokoll enthält. Dieses wiederum können Sie nur lesen, nachdem der Systemstart erfolgreich verlief. Um dieses Problem zu umgehen speichert Suse Linux in der Datei boot.omsg auch das Protokoll des vorletzten Startvorganges.

Suche nach Verdächtigen

Zwei weitere Protokolldateien, die Sie kennen sollten sind /var/log/warn und /var/log/wtpm. Erstere Datei existiert wiederum nur unter Suse Linux. Bei letzterer handelt es sich um eine Datei im Binärformat, die sich über den Befehl last lesen lässt. Sie führt Protokoll über sämtliche An- und Abmeldevorgänge am System. Die Datei ist deshalb keine normal lesbare Textdatei, damit Eindringlingen das Fälschen von Einträgen so schwer wie möglich gemacht wird. Wie bei vielen anderen Protokolldateien auch, enthält die Datei nur die aktuellsten Daten. Ältere Einträge verschiebt das System in separate Dateien und komprimiert diese, damit die Logfiles nicht zu viel Platz beanspruchen. Je nach Einstellung der Distribution löscht Linux dann die Protokolldateien nach einer gewissen Zeit ganz. Suse Linux legt zum Beispiel alle zwei Wochen eine neue Protokolldatei für /var/log/wtpm an.

Neben last, das alle Anmeldevorgänge protokolliert, gibt es auch noch den Befehl lastlog. Er zeigt für alle Benutzer, wann sie sich zum letzten Mal angemeldet hatten.

In /var/log/warn speichert das System alle kritischen Warnungen des Kernels. Hier tummeln sich Hardware- und Softwarefehler, sowie Einträge über die Firewall oder das Powermanagement. Ein Blick auf diese Datei lohnt sich deshalb bei allen ungewöhnlichen Vorkommnissen. Für den Durchschnittsbenutzer sind die Meldungen allerdings oft nicht zu entschlüsseln, auch stellt nicht jede Meldung grundsätzlich ein Problem dar. Eine Suche nach Error kann aber zusätzliche Hinweise bei der Fehleranalyse liefern. Auch hier lohnt es sich, Datum und Zeit des kritischen Eintrages zu notieren, dann in /var/log/messages nach zeitgleichen Ereignissen zu suchen. (mhi)

Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen.

Druckerfreundliche Version | Feedback zu dieser Seite | Datenschutz | © 2021 COMPUTEC MEDIA GmbH | Last modified: 2007-04-05 11:10

[Linux-Magazin] [LinuxUser] [Linux-Community]