Fehlermeldung

Fehlermeldungen lassen sich unter Linux wie folgt als root hier nachvollziehen:

tail -f /var/log/messages

---

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

Dieser Artikel entsteht in den nächsten Wochen hier so nach und nach komplett neu. Da zT.auch offline daran gearbeitet wird, bitte ich vorerst von Änderungen aller Art abzusehen, da diese sonst allzuleicht verloren gehen könnten. --Robi 01:50, 18. Okt. 2007 (CEST)

( folgendes Menü dient vorerst nur mal so als Gedankenstütze und Arbeitsgrundlage )

Fehlermeldungen

Allgemeines und trockene Theorie zu Fehlern und Meldungen

Wer kennt sie nicht, diese Fehlermeldungen. Sie sind bei Weitem nicht immer eindeutig und leicht verständlich, teils sind sie sogar hoch kryptisch und beinhalten nur unverständliche Zahlen oder Zeichenkombinationen, mal sind sie so unverständlich verwirrend in der Wortwahl, dass man darüber nur schmunzeln kann, dann wieder absolut irreführend, und dennoch für das geübte Auge und den erfahrenen Anwender sind sie doch meist hilfreich.

Wo und wie entstehen Meldungen

Wer hat sich schon einmal Gedanken gemacht, wo diese Fehlermeldungen entstehen und wie sie den Weg auf den Bildschirm oder in die Fehlerlogdateien finden?

Die gesamte Software ist nicht aufgebaut wie ein Faden mit nur einem Anfang und einem Ende, sondern hochgradig modular und besteht aus vielen kleinen Bausteinen mit bestimmten Aufgaben, die wiederum andere universelle Bausteine aufrufen, und so weiter. Während des Programmablaufes werden an aufgerufene Bausteine Werte als Parameter übergeben und von dort Rückgabewerte entgegengenommen. Anhand der Werte der Übergabeparameter werden auch Entscheidungen getroffen, welcher Baustein wann wie aufgerufen wird. An wichtigen Punkten und Verzweigungen innerhalb des Programmablaufes wird jeder Programmierer während der Entstehung und des Tests der Software Meldungen erzeugen lassen, um den ordnungsgemäßen Ablauf nachzuvollziehen. Die meisten dieser Meldungen werden vor der Fertigstellung dann jedoch entfernt, die Meldungen über die wichtigsten Ereignisse bleiben jedoch oftmals auch in der fertigen Software enthalten und können meistens über Parameter an- oder abgeschalten werden. Solche Meldungen kommen immer wenn der entsprechende Abschnitt der Software durchlaufen wird. In bestimmten Bereichen der Software sind also mehr oder weniger viele planmäßige Meldungen enthalten.

Es gibt aber auch Meldungen die weniger planmäßig sind.

Sie entstehen nicht, solange bei der Abarbeitung die einzelnen Werte der Parameter in ihren jeweils vorherbestimmten Wertebereichen bleiben. Erst wenn ein Software Baustein auf einen undefinierten oder ungültigen Wert stößt, oder dieser Wert von vorne herein schon als Fehlerwert definiert ist, gibt es ein Problem, da für diesen Wert in dieser Funktion ja auch keine Lösungsregel definiert ist. Also soll jetzt die Funktion diesen Wert ignorieren? korrigieren? Das geht in den untersten Funktionen nicht, diese sind viel zu universell geschrieben, um zu wissen was da irgendwo oben falsch laufen könnte. Also eine negative Rückmeldung an die aufrufende Funktion schicken, vielleicht weiß diese damit etwas anzufangen, oder wollte evtl. nur auf Gültigkeit des Wertes testen und rechnet mit einer negativen Rückmeldung. Hat die aufrufende Funktion keine logische Erklärung für die negative Rückmeldung, steht die Frage, ist in dieser Funktion eine solche, jetzt Fehlersituation, vorgesehen: dann wird die entsprechend darauf reagieren, ansonsten gibt auch sie eine negative Rückmeldung an ihre aufrufende Funktion zurück. Irgend ein übergeordneter Baustein wird dann auf diese Ausnahmesituation reagieren, entweder ist dieses Problem irgendwo definiert und vorhergesehen, oder es muss an einer Stelle eine Fehlermeldung ausgegeben werden und entschieden werden, Abbruch oder korrigieren oder ignorieren und weiter machen. Je genauer der Programmierer bei der Erstellung der Software vorhersehen konnte, wo ein Problem entstehen könnte und wodurch ein falscher Wert in einer der Unterfunktionen zustandekommen könnte, um so genauer könnte jetzt die Fehlermeldung erstellt und ausgegeben werden. Werden solche Fehler nicht innerhalb der Software gemeldet, registriert und abgefangen, dann beendet sich der Prozess ohne jegliche Meldung oder er läuft mit fehlerhaften Werten weiter und wird entsprechend auch falsche Ergebnisse liefern. Beides ist entweder schlechter Programmierstil oder wirklich ein absolut unvorhersehbarer Fehler und sollte im Normalfall die absolute Ausnahme sein.

Es ist also für den Programmierer nicht immer möglich jede Fehlersituation vorauszuahnen und dafür dann auch noch aussagekräftige Meldungstexte zur Verfügung zu stellen. Viele Meldungen enthalten deshalb auch zum genauen spezifizieren Parameter- oder Flagwerte oder gar nur vordefinierte Fehlercodes. In diesem Fall hilft dann nur ein Blick in den Quellcode (meist den Headerdateien) beim genaueren Untersuchen einer solchen Meldung.

Ein Prozess ist mit den Prozessen und all den Funktionen die er erzeugt und benutzt über eine gemeinsame Prozessumgebung verbunden. Zur Prozessumgebung gehört auch der Standardfehler-Kanal. Über diesen Kanal werden in aller Regel solche Meldungen ausgegeben. Die Meldungen irgend einer universelle Funktion werden sich also immer in den Standardfehlerkanälen der Prozesse finden, die diese Funktion fehlerbehaftet benutzt haben. In diesen Standardfehlerkanal eines Prozesses werden sich also alle planmäßigen und unplanmäßigen Meldungen eines Prozesses und all seiner Unterfunktionen wiederfinden, soweit diese nicht stellenweise gezielt in den Papierkorb umgeleitet werden. Bei Programmen die wir auf der Konsole starten, ist das ja auch sehr schön erkennbar, aber es gibt auch Prozesse die gar keine Konsolausgabe haben. Dazu gehört zB der Kernel selbst, Dienste die im Hintergrund laufen und Programme, die die grafische Oberfläche als Aus- und Eingabe nutzen, aber dazu später.

ist jede Meldung wirklich ein Fehler

Wenn wir von Fehlern reden, müssen wir uns immer im klaren sein: Fehler für wen oder was? Starten wir zB ein Programm auf der Konsole und erhalten eine Fehlermeldung etwa folgender Art:

bash: programm: un*: Datei oder Verzeichnis nicht gefunden

Erst einmal eine Meldung, aber ein Fehler für wen?
Linux an sich, dem Kernel oder seiner Bestandteile? Wohl kaum, das arbeitet normal weiter und macht genau das was er soll.
das Programm welches wir aufgerufen haben? Für das Programm gab es auch keinen Fehler, es ist vielmehr gar nicht erst gestartet worden.
hier hat eindeutig die bash den Fehler gemeldet.

Nicht überall und immer ist es eindeutig wie in diesem Beispiel, aber es ist bezeichnend. Bekommen wir jetzt diese Zeile bei einem Kommandoaufruf in der Konsole, dann ist es streng genommen nur eine Meldung die uns einen falschen Befehlsaufruf quittiert. Bekommen wir jetzt diese Meldung jedoch von einem Script, dann wird die selbe Meldung streng genommen zu einer Fehlermeldung, und zwar eines Fehlers dieses Scripts. Wurde dieses Script schon mit der Distribution ausgeliefert, dann ......

Anderes Beispiel:
Versuchen wir zB einen Treiber für ein Gerät, welches wir gar nicht im Rechner haben, zu laden, dann wird dieser Treiber natürlich auch kein Gerät finden und eine entsprechende Meldung ausgeben. Aus Sicht des Treibers ist das ein absolut tödlicher Fehler, für den Kernel, der den Treiber laden will oder das Startscript, das den Treiber laden soll, bleibt es immer noch ein Fehler und zwar beim Laden des Treibers, für das Linux-System als Ganzes jedoch bleibt es solange nur eine Meldung, solange dadurch keinerlei Funktionseinschränkungen verbunden sind.

So müssen wir viele dieser Meldungen interpretieren. Besonders dort wo wir viele dieser Meldungen vorfinden, in den Logdateien und beim Systemstart. Erst einmal ist jede dieser Meldungen einzeln gesehen nur eine Meldung, auch wenn dort irgendwas von Error, failed oder was auch immer steht. Selbst beim genauen untersuchen jeder einzelnen Meldung bleiben die meisten auch dann immer noch ganz normale Meldungen. Wenn wir einzelne Meldungen als Fehlermeldungen bezeichnen wollen, müssen wir immer dazu interpretieren, für wen das ein Fehler ist. Eine Fehlersituation ist nicht selten aus einer einzelnen Zeile heraus überhaupt nicht zu erkennen, dazu müssen mehrere Meldungen, die auch nicht unbedingt immer aufeinander folgend ausgegeben werden, als Ganzes herangezogen werden. Manchmal ist auch das Fehlen einer einzelnen Meldung in einer ganzen Abfolge von Meldungen der eigentliche Fehler.

---

Welche Meldung findet man wo

Meldungen des Kernels

Der Kernel ist das Herzstück des Betriebssystems und läuft für den Anwender unbemerkt im Hintergrund. Im Kernel und von dessen Modulen werden aber jede Menge Meldungen erzeugt. Einen Teil davon sehen wir beim Hochfahren oder Beenden des Systemes auf dem Bildschirm. Es handelt sich aber hier zum Teil auch schon um verarbeitete Meldungen und Ausgaben der Start/Stopp-Scripte. Im laufenden System kann man mit der Tastenkombination ALT + STRG + F1 auf die Konsole wechseln auf der diese Ausgaben gemacht werden. Viele Kernelmeldungen fallen jedoch schon an, wenn noch gar keine andere Software in der Lage ist, diese weiter zu verarbeiten oder sie irgendwohin zu schreiben. Der Kernel hat aus diesem Grund ein eigenes Fehlerloggingsystem. Es handelt sich hierbei um einen Ringbuffer, der sich mit dem Kernel im Hauptspeicher befindet. Hier hin werden alle Kernelmeldungen geschickt. Ist der Ringbuffer voll, werden die jeweils ältesten Daten überschrieben. Als User haben wir einen direkten lesenden Zugriff auf die Meldungen innerhalb dieses Ringpuffers mit Hilfe des Befehls dmesg. Hier können wir die jeweiligen Meldungen seit Beginn des Startens des Kernel jeweils nachlesen. Da es sich um einen Ringpuffer handelt, der zB bei Treiberproblemen auch schnell volllaufen könnte, werden die Meldungen nach dem booten oftmals automatisch mit

 
 /bin/dmesg > /var/log/boot.msg

oder ähnlichem Namen abgelegt. Und können somit auch später noch eingesehen werden, wenn der Puffer schon die Startsequenz überschrieben hat.

Mit dmesg können wir uns also alle Kernelmeldungen anschauen, unabhängig von ihrer Gewichtung sind hier auch jede Menge informeller Meldungen enthalten, die im Systemlog meist schon weggefiltert sind. Mit deren Hilfe kann man die erkannte Systemhardwarekonfiguration nachvollziehen. Die Meldungen hier haben aber keinerlei Zeittempel, so dass man nur wage Rückschlüsse auf eine genaue Entstehungszeit machen kann. Es gibt kein einheitliches Layout, viele Ausgaben sind aber so formatiert, dass der Treiber oder das Gerät am Anfang durch einem Doppelpunkt von der Meldung getrennt steht.

Das System-Logging

Linux bedient sich eines komplexen Loggingsystems dem Syslog. Der Syslog wird durch eine Daemon Namens syslogd beim Systemstart über ein Script gestartet. Dieser Daemon nimmt Meldungen direkt vom Kernellogger sowie alle Nachrichten die mit dem Systembefehl syslog von irgend einem laufenden Prozess gesendet werden, entgegen. ( Von der Konsole oder aus einem Script heraus gibt es die Möglichkeit Nachrichten mittels des Befehles logger an den Syslogd zu senden.) Dieser Logdienst ist insbesondere für andere Daemon-Prozesse wichtig, die ja keinen Terminal zur Ausgabe haben und auch sonst gar nicht wüßten an wen oder wohin sie ihre Fehlermeldungen oder sonstige Meldungen senden sollten. Auf den meisten Linuxrechnern werden die lokalen Nachrichten auch lokal vom syslogd verarbeitet, doch da dieses Loggingsystem netzwerkbasierend ist, ist es auch möglich die Informationen an einen anderen Rechner zu senden, um sie dort weiter auszuwerten. Es ist also durchaus möglich einen Syslogserver zu betreiben, der dann alle Informationen von "befreundeten" Rechnern verarbeitet. Dieses ist zB ratsam bei Rechnern in der "Ersten Reihe", die verstärkten Anriffen aus dem Internet ausgesetzt sind. Erfolgreiche Angriffe lassen sich so nicht so einfach durch das Manipulieren der Loggingdateien verschleiern.

Konfiguration von syslog

Die Meldungen für den Syslogd unterliegen einem Protokoll und beinhalten außer dem eigentlichem Meldungstext noch Angaben zum Absenderrechner, Zeitstempel und eine Herkunftskategorie und eine Meldungspriorität.

Die wichtigesten unter Linux benutzten Herkunftskategorien

Kategorie	Bemerkung
kern	Systemmeldungen direkt vom Kernel
auth	Meldungen vom Sicherheitsdienst des Systems (login usw.)
authpriv	Vertrauliche Meldungen der internen Sicherheitsdienste
cron	Meldungen des Cron-Daemons
mail	Meldungen des Mail-Systems
news	Meldungen des News-Systems
lpr	Meldungen des Druckerdaemons
syslog	Meldungen des syslog-Daemons selbst
daemon	Meldungen anderer Daemon-Prozesse
user	Meldungen aus Anwenderprogrammen
uucp	Meldungen des UUCP-Systems
local0 ...local7	frei verwendbar

Anhand der Meldungspriorität kann Syslog Meldungen zwischen Informativ - Warung - Fehler - Tötlicher Fehler unterscheiden.

Prioritäten in absteigender Reihenfolge

Kategorie	Bemerkung
emerg	Panic "letzte Spruch vor dem Absturz"
alert	Alarmierende Situation, "sofortiges Eingreifen erforderlich"
crit	Meldung über eine kritische Situation "gerade nochmal gut gegangen"
err	Fehlermeldungen aller Art aus dem laufenden Betrieb
warn	Warnungen aller Art aus dem laufenden Betrieb
notice	Dokumentation besonders bemerkenswerter Situationen im Rahmen des normalen Betriebs
info	Protokollierung des normalen Betriebsablaufes
debug	Mitteilungen interner Programmzustände bei der Fehlersuche
none	keine richtige Priorität, sondern dient zum Ausschluß einzelner Herkünfte

Anhand der Herkunft und der Priorität einer Meldung entscheidet syslogd was mit dieser Meldung gemacht werden soll.

Es gibt folgende Möglichkeiten:

• Schreiben in eine Datei
• Übergabe an eine "Named Pipe"
• Ausgabe auf der Konsole
• Weitergabe an den Syslogd eines anderen Rechners
• Ausgabe auf dem Terminal eines oder mehrer spezieller User
• Ausgabe auf dem Terminal jedes angemeldeten Users.

Die Informationen was jetzt mit welcher Meldung gemacht wird, bezieht "syslogd" aus der Konfigurationsdatei /etc/syslog.conf.

(genaue Beschreibung für die Konfiguration der /etc/syslog.conf und auch Beispiele sind sowohl in der Manpage von syslogd als auch syslog.conf reichlich vorhanden)

Wichtige Logdateien von syslog

Nun könnte theoretisch jeder seinen syslogd anhand der oben genannten Konfigurationsmöglichkeit anders konfigurieren und seine Meldungen irgendwohin unter irgend einem exotischem Namen ablegen. Auf den meisten Linux-PCs besteht dazu jedoch überhaupt keine Notwendigkeit dazu, so dass an dieser Stelle von den meisten Usern nichts gegenüber dem default der Distibution ändern wird. Änderungen sind jedoch desöfteren auf als Server betriebenen Maschien vorzufinden, wobei man sich aber größtenteils an gewisse Regeln hält, weshalb hier an dieser Stelle nur der Default vorgestellt wird.

• unter Linux sind die Logdateien des Syslogs unterhalb von /var/log zu finden.
• /var/log hat keine Leseberechtigung für Normaluser
• Meldungen mit der Priorität emerg bekommt jeder angemeldete User auf das Terminal
• Meldungen (auser von authpriv) mit Priorität >=err und vom Kernel >=warning gehen auf die Konsole und X-Konsole
• Meldungen >=alert gehen auf das Terminal von Root
• Meldungen >=warning werden in die Datei /var/log/warn geschrieben
• Meldungen der Herkunft local0...local7 werden in die Datei /var/log/localmessages geschrieben
• Alle Meldungen werden nach /var/log/allmessages geschrieben (meist deaktiviert)
• Alle Meldungen außer von mail und news werden nach /var/log/messages geschrieben
• mail und news Meldungen werden in Dateien unterhalb von /var/log geschrieben. Am Dateinamen ist Herkunft und Priorität erkennbar. (zB. /var/log/news/news.err beinhaltet alle Meldungen von news >= err)

Daraus ergeben sich (wenn wir Mail und News vernachlässigen) 3 Dateien die in denen wir Probleme aus dem Syslogdienst suchen könnten.

/var/log/localmessages

Hier könnten von einigen Startscripten oder spezielle Diensten Meldungen abgelegt sein. Auch die Meldungen unsere eigenen Scripte müßten hier aufschlagen. Einfach einmal einen Blick in diese Datei riskieren, nur um zu sehen welches Program hier überhaupt Meldungen ablegt.

/var/log/warn

Das sollte der erste Anlaufpunkt sein wenn es Problem gibt. Diese Datei ist gut geeignet um erst einmal Fehlerhäufigkeit und genaue Zeitpunkte von Fehlern zu erkennen.

/var/log/messages

Hier sollte alles zusammenlaufen. Dadurch ist diese Datei jedoch auch meistens etwas größer und unübersichtlicher. Häufig hilft in der Ausgabe Unwichtiges und häufige Ausgaben erst einmal mit grep -v ... wegzufiltern.

Das Format der Meldungen in allen Dateien ist vom Aufbau-Prinzip gleich. Die ersten Felder sind relativ einfach aufgebaut. Der Fehlermeldungstext und die genaue Herkunft kann aber durchaus unterschiedlich formatiert ausfallen, so dass es nicht leicht ist, mit Automatismen eine Auswertung einer solchen Datei zu programmieren.

die Felder im Einzelnen:

Zeitstempel

es ist der Zeitstempel des Eintreffens beim Syslogd. Entsprechend der im Rechner eingestellten Lokalen, kann das Ausgabeformat der Zeit hier von Rechner zu Rechner unterschiedlich ausfallen. Der Zeitstempel der Erstellen der Meldung wird auf ein und dem selben Rechner der selbe sein, wenn die Meldung an einen anderen Rechner weitergeleitet ist, kann sie aber durchaus auch anders sein. Einige Meldungen beinhalten desshalb noch einmal den Entstehungszeitstempel in der Meldungsausgabe.

 Jul 19 23:21:39 pingu nmbd[2936]: [2007/07/19 23:21:39, 0] nmbd/nmbd_become_lmb.......

Rechnername ( in Ausnahmefällen IP )

Das wird erst von Interesse wenn wir die Meldungen an einen anderen Rechner weitergeleitet haben. Das lokale Logging wird immer den Namen unseres Rechners haben.

der Absender

hier steht der Absender der Nachricht gefolgt von einem Doppelpunkt. Das kann der kernel: sein aber auch irgend ein Dienst (zB. sshd[4189]: bedeutet der sshd mit der ProzessID 4189) oder auch ein ganzer Path eines Programmes. Das Absenderfeld kann dabei auch Leerzeichen enthalten. ( zB. gconfd (rob-5766): ) endet also immer erst mit dem ersten Doppelpunkt nach dem Rechnernamen.

optional kann dann noch eine oder mehrere Erweiterung und nähere Bezeichnung des Absenders stehen. Der kernel aber auch andere Programme benutzt bisweilen solche Erweiterungen, um das Modul oder die Instanz näher zu bezeichnen. Jede dieser Erweiterungen endet wieder mit einem Doppelpunkt. (zB. kdm: :0[5630]: pam_unix2: würde bedeuten: Absender ist kdm 1. Erweiterung keine 2. Erweiterung Xserver 0 ProzessID5630 3. Erweiterung modul pam_unix2 )

Diese Erweiterungen kann man aber auch schon als Teil der eigentlichen Meldung auffassen

Am Ende steht dann der Wortlaut der eigentlichen Meldung.

Unterbrochen sind solche Meldungen in der /var/log/messages gelegentlich durch einen -- MARK -- Eintrag. Dieses ist eine Funktion des syslogd selbst und sollte im Defaultfall all 20 Minuten ein funktionieren des Rechners und des Syslog dokumentieren

Sollten sich Meldungen innerhalb kurzer Zeit oftmals wiederholen, dann erkennt das der syslogd und bringt anstatt der sich ständig wiederholenden Meldung eine Meldung analog:

warn:Sep 27 23:27:09 pingu last message repeated 84 times

Welche zb hier ausdrückt, dass sich die letzte Meldung noch 84 Mal innerhalb kurzer Zeit wiederholt hat.

---

---

---

Weiterführende Links

Konsole