Generelles Troubleshooting

Bewertung:1

---

Die Kandidaten sollten in der Lage sein, Bootloader und Kernelspezifische Stufen zu erkennen und zu identifizieren und die Kernel-Bootmeldungen zu benutzen, um Kernel-Fehler zu diagnostizieren. Dieses Prüfungsziel beinhaltet die Erkennung und Behebung häufiger Hardware-Fehler und die Fähigkeit einzuschätzen, ob einem Problem ein Soft- oder Hardwarefehlern zugrundeliegt.

Schlüsseldateien, Begriffe und Hilfsmittel beinhalten:

• Bildschirmausgabe während des Bootens
• dmesg
• Die Kernelmeldungen in den Systemlogbüchern (sofern sie zugänglich sind)
• Verschiedene System- und Daemon Logfiles in /var/log
• /sbin/lspci
• /usr/bin/lsdev
• /sbin/lsmod
• /sbin/modprobe
• /sbin/insmod
• /bin/uname
• Lokalisierung des System-Kernels und seiner passenden Module (/, /boot und /lib/modules)
• Das /proc Dateisystem
• strace
• strings
• ltrace
• lsof

---

Die meisten der hier gestellten Anforderungen sind durch andere Kapitel dieser Dokumentation bereits abgedeckt. So haben wir den Umgang mit den Logbüchern im Kapitel 2.211.1 kennengelernt, lspci und lsdev wurden im Abschnitt 2.204.2 besprochen und die Befehle zum Umgang mit Kernelmodulen (lsmod, modprobe und insmod ) waren Thema im Abschnitt 2.201.4.

Die grundsätzliche Aufgabenstellung dieses Prüfungsziels ergibt sich eigentlich aus dem gesunden Menschenverstand (gepaart mit dem Verständnis von Linux im Allgemeinen) und der Kenntnis der verschiedenen Hilfsmittel. Aus diesem Grund werden hier noch einmal die bisher nicht besprochenen Utilities angesprochen, die in den Schlüsselbegriffen genannt sind.

Überprüfen der Kernelmeldungen mit dmesg

Der Kernel schreibt seine Meldungen nicht nur an den Syslog-Daemon, sondern auch in einen Ringbuffer im Speicher. In diesem Buffer sind alle wichtigen Meldungen enthalten, die die letzte Zeit angefallen sind. Ein Ringbuffer besteht aus einer Speicherverwaltung, die eine vordefinierte Größe besitzt, und deren Beginn dann überschrieben wird, wenn das Ende des Speicherplatzes erreicht ist. Um diesen Ringbuffer zu lesen, existiert das Programm {\bf dmesg}.

Mit einem einfachen

  dmesg | less

kann also der Inhalt des Buffers gelesen werden, mit

  dmesg > Datei

kann er in eine statische Datei geschrieben werden.

Aktuelle Informationen mit uname erfragen

Um bestimmte aktuelle Informationen über das System und den Kernel zu bekommen, existiert das Programm uname. Dieses Programm kennt folgende Kommandozeilenparameter:
• -a
  gib alle Informationen aus (auch \verb+-all+)
• -m
  gibt dem Maschinentyp (z.B. i686) zurück (auch \verb+-machine+)
• -n
  gibt den Rechnernamen (nodename) zurück (auch \verb+-nodename+)
• -r
  gibt die Kernel Release Nummer zurück (auch \verb+-release+)
• -s
  gibt den Betriebssystemnamen zurück (auch \verb+-sysname+)
• -p
  gibt den Prozessortyp zurück (auch \verb+-processor+)
• -v
  gibt das Datum der Kernelerstellung zurück

Das können sehr wichtige Informationen sein, denn in einigen Fällen muss auf bestimmte Verzeichnisse zugegriffen werden, die z.B. nach der Release-Nummer des Kernnels benannt sind. Die Module jedes Kernels liegen immer im Verzeichnis /lib/modules/Kernelversion. Wenn jetzt mit unterschiedlichen Kernelversionen gearbeitet wird, so kann über den Befehl uname -r genau herausgefunden werden, in welchem Verzeichnis diese Module liegen. Es ist sogar möglich das - via Kommandosubstitution - gleich in eine Zeile zu schreiben:

  cd /lib/modules/`uname -r` 

Das in Grave-Zeichen gesetzte uname -r wird von der Shell durch seine Ausgabe ersetzt, also etwa durch 2.4.18. Wir wechseln also ins Verzeichnis /lib/modules/2.4.18.

Fehler in Programmen mit strace und ltrace finden

In manchen Fällen stürzen Programme ohne offensichtlichen Grund einfach ab. Vielleicht werden so vielsagende Fehlermeldungen wie "Speicherüberlauf" oder "Segmentation Fault" ausgegeben, die uns aber auch nicht wirklich weiterhelfen. Um genauer herauszufinden, wo die Ursache des Programmabsturzes liegt, gibt es die Programme strace und ltrace. Beide verhalten sich sehr ähnlich, überprüfen aber unterschiedliche Dinge.

strace wird zusammen mit dem zu untersuchenden Programm aufgerufen. Das heisst, das zu untersuchende Programm wird strace als Parameter mitgegeben. Das Programm strace startet jetzt das zu untersuchende Programm und gibt alle Systemaufrufe und Signale auf der Standard-Fehler-Ausgabe aus, die von dem Programm abgearbeitet wurden. Wenn das Programm dann wieder an der üblichen Stelle abstürzt, so kann meist durch die letzte ausgegebene Systemaufrufsmeldung der Fehler eingegrenzt werden.

Das Programm ltrace arbeitet im Prinzip genauso wie strace, nur dass es statt der Systemaufrufe und Signale eben Library-Aufrufe verfolgt. Fehler, die durch fehlende oder falsche shared libraries entstehen, können mit ltrace gefunden werden.

Das Programm strings

Viele Binärdateien - insbesondere Programmdateien - enthalten neben vielen undruckbaren Zeichen einige lesbare Zeichenketten, die womöglich während der Fehlersuche wichtige Hinweise geben können. Da die manuelle Suche solcher Zeichenfolgen sehr mühsam ist, gibt es das Programm strings, das aus einer Binärdatei die lesbaren Zeichenketten (mit mindestens 4 aufeinanderfolgenden druckbaren Zeichen) auf der Standard-Ausgabe anzeigt.

Offene Dateien anzeigen mit lsof

Im Bereich des Troubleshootings ist es oft notwendig zu wissen, welche Dateien gerade geöffnet sind. Um das herauszufinden, existiert das Programm lsof (List Open Files). Über verschiedene Kommandozeilenparameter kann angegeben werden, welche Art von offenen Dateien angezeigt werden sollen.

 

 

---

[ Zurück zur Startseite LPI 201 ] [ Zurück zur LPI-Seite ] [ Zurück zur Hauptseite von Linux-Praxis ] [ Guestbook ] [ Kontakt ]

---

Diese und die darunterliegenden Seiten wurden erstellt von F. Kalhammer

© 2001 by F.Kalhammer -
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License..

---