Hallo allerseits, ich möchte von dem Treffen der Lug Owl von Montagabend berichten: Wer kennt das nicht: Ein Linux-Programm läuft nicht so, wie es eigentlich sollte. Und die Ursache ist unbekannt. Helfen Manpages und Änderungen der Aufrufparameter nicht weiter, sind Tools gefragt, die tiefere Einblicke ermöglichen. An dieser Stelle kommt strace ins Spiel. Weil der Einsatz von strace keine besonderen Vorkehrungen benötigt, kann jedes Programm untersucht werden. Darin unterscheidet sich strace von Debuggern. Ihr Einsatz ist sinnvoll, falls das zu untersuchende Programm dafür vorbereitet ist. Programme, die von kommerziellen Firmen stammen, enthalten selten Debbuging-Informationen. Solche Firmen lassen sich eben nicht so gerne in die Karten schauen. (Unter Linux kann man das aber nicht wirklich verhindern. Das stellte sich an diesem Abend heraus). Strace gewährt im Regelfall keinen Einblick in die Semantik eines Programmes. Dafür setzt man Disassembler ein. Das Diassemblieren ist aber aufwendig und setzt Kenntnisse der Maschinenprogrammierung voraus. Deshalb sind häufig lstrace oder strace das Mittel der Wahl. Ltrace geht einen Schritt weiter als strace. Ltrace listet alle internen Funktionsaufrufe, strace nur die Betriebssystemaufrufe. Ltrace arbeitet daher genauer, erzeugt aber auch viel mehr Output bis hin in den Megabyte-Bereich. Das Mehr an Informationen verstellt mitunter den Blick auf das eigentlich Wichtige. Deshalb startet man am besten mit strace. Strace spiegelt das Geschehen an der Schnittstelle zwischen Programm und Betriebsystem wieder. In vielen Fällen erlaubt dieses Geschehen einen Rückschluß auf die Funktionsweise des fraglichen Programmes. Versucht das Programm beispielsweise, eine nicht nicht vorhandene Datei zu öffnen, könnte es daran liegen, dass das Programm im falschen Verzeichnis sucht. Und das könnte daran liegen, dass das Programm im falschen Verzeichnis gestartet oder der Suchpfad in der Variablen PATH falsch gesetzt wurde. Solche Schlüsse zu ziehen, sind das tägliche Brot beim Einsatz von strace. Dafür bietet strace eine Fülle von Ausgangsinformationen. Man kann genau erkennen, wann und wie welche Dateien, Bibliotheken, Betriebssystemfunktionen und dergleichen benutzt werden. Ist man sich darüber im Klaren, wie das fragliche Programm prinzipiell funktionieren müßte, kann man die Stelle, an der es hakt, lokalisieren. So werden Rückschlüsse auf Fehlerursachen möglich. Wie man dabei systematisch vorgeht, war Thema des Vortrages von Jan-Benedict Glaw. In seiner überaus kompetenten Art beleuchtete er das Thema von allen Seiten. Ausgehend von der Funktionsweise von strace definierte er den Einsatzraum und die Grenzen der Erkenntnismöglichkeiten, um sodann anhand mehrerer Beispiele die Vorgehensweise bei der Analyse praktisch vorzustellen. Das typische Ablaufmuster eines Linux-Programmes, beginnend mit dem Aufruf über die Shell, das Allozieren des Hauptspeichers, das Laden des Programmcodes, das Nachladen der benötigten Libraries, das Einbinden von Eingabe- und Ausgabeprozeduren, das Nutzen von Files und Hardwarekomponenten stellte JBG anhand der strace-Ausgaben so plastisch dar, das es leicht nachzuvollziehen war. Detailiert ging JBG darauf ein, wie die Ausgabe von strace zu interpretieren ist, welche Rückschlüsse auf das zu untersuchenden Programmes möglich und wo weitere Informationen im Linuxsystem zu finden sind. Am Schluß zeigte sich, dass mit der Beobachtung einer Handvoll Betriebssystemaufrufe über strace das Geschehen an der Schnittstelle zwischen Betriebssystem und Programm sehr genau erfaßt werden kann (vgl. angehängte Liste). Mit der entsprechenden Option von strace oder durch den Einsatz von grep kann die Datenfülle erheblich reduziert werden, so dass nichts mehr von der Analyse ablenkt. Die Zuhörer zu dieser Erkenntnis zu führen, ohne sie zu überfordern und ohne sich durch die vielen Fragen von seinem roten Faden ablenken zu lassen, zeichnet den Vortragsstil von JBG aus. Die Fülle seiner praktischen Tipps werden manchen Zuhörer stundenlanges Suchen und Grübeln ersparen. Und so ganz nebenbei und völlig unauffällig gewannen die Zuhören einen tiefen Einblick in das interne Geschehen von Linux. So hat JBG an diesen Abend zwei Fliegen mit einer Klappe geschlagen. Kein Wunder, dass die Diskussion erst mitten in der Nacht endete. Dank der Organisation von Thomas Balls-Thies stand ein Computerraum im ZiF zur Verfügung. Bei dem Zif handelt es sich um ein der Universität Bielefeld angegliedertes Institut. Die Atmosphäre des Zif's eignet sich für einen solchen Vortrag perfekt. Ich erlaube mir, im Namen aller Teilnehmer zu sprechen, wenn ich beiden für ihren gelungenen Einsatz gratuliere. Grüße Peter Voigt -------------------------------------------------------------------- Liste der wichtigsten Betriebssystemfunktionen, die beispielsweise über strace -e trace=........ (alternativ mit Hilfe von grep .......) gefiltert werden können: open/close Datei öffnen/schließen read/write/send/recv/sendto/recvfrom Lesen/Schreiben von/an einen Datei-Descriptor mmap Datei-Bereiche im Speicher sichtbar machen fork Programm duplizieren exec Ein anderes Programm starten; das ehemalige Programm geht dabei "seinen letzten Gang" exit Programm beenden, Return-Wert hinterlassen stat/fstat/lstat Datei-Eigenschaften (Größe, Device Node?, ...) abfragen pipe Kommunikations-Kanal (Strohhalm mit zwei Enden) erstellen dup2 Gezielt einen Datei-Descriptordurch einen anderen ersetzen wait Kindesleichen wegräumen (sonst gibt's Zombies) socket Netzwerk-"Henkel" erzeugen connect Ziel für Netzwerk-Verbindung festlegen bind/listen/accept (Serverseitig) Verbindungen annehmen poll/select Prüfen, ob von einem Datei-Descriptor Daten gelesen werden können.