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.

---

---

---

Weiterführende Links

Konsole