Um abgestürzte oder hängende Prozesse zu untersuchen, kommt normalerweise ein Debugger zum Einsatz. Es geht aber auch anders: Mit Strace sehen Sie Programmen direkt bei der Arbeit zu.

Sicher kennen Sie die Situation: Ein – zumeist recht komplexes – Programm verhält sich ganz und gar nicht so, wie Sie es kennen und erwarten. Plötzlich stürzt es mit einer Reihe völlig unverständlicher Fehlermeldungen ab oder startet gar nicht erst, obwohl es am Vortag noch ohne jedes Problem lief. Sofern Sie zwischenzeitlich kein Update eingespielt haben – und auch keines für die von dem Programm verwendeten Komponenten – gibt es eine gute Chance, dem Problem mit Strace [1] auf die Schliche zu kommen. Falls allerdings doch eine Aktualisierung erfolgte, sollten Sie zunächst prüfen, ob dabei alles korrekt verlief und ob die Konfigurationsdateien noch funktionieren.

Ein routinierter Programmierer dürfte beim Auftreten von Fehlern wohl als Erstes zum Quelltext des Programms greifen, wenn er ein ungewöhnliches Verhalten bemerkt. Bringen Sie dafür zu wenig Erfahrung mit oder fehlt Ihnen schlicht die nötige Leidensfähigkeit – und wer möchte schon gern ein komplexes Programm wie etwa Digikam debuggen? –, dann setzen Sie stattdessen Strace darauf an, zur Laufzeit den Fehler aufzuspüren.

Grundlagen

Bei Strace ist der Name Programm: Das Tool “traced”, also verfolgt, alle Systemaufrufe und Signale. Dazu verändert es die Funktionen so, dass deren Aufruf protokolliert wird. Das erfolgt auf einem von zwei möglichen Wegen: Läuft das zu untersuchende Programm bereits, ermitteln Sie zunächst mittels Top, Ps oder Pidof dessen Prozess-ID (PID), die Sie Strace dann über die Befehlszeilenoption -p mitteilen. Generell erfolgt ein Aufruf dann nach folgendem Schema:

$ strace -p PID ... Optionen

Als einfacher erweist es sich aber, schon vor dem Start des Programms mittels Strace die System-Calls abzufangen. Ein entsprechender Aufruf zeigt folgende Struktur:

$ strace Optionen ... Programm

Beendet sich das mittels Strace beobachtete Programm, so terminiert auch das Tool automatisch.

Viele der Optionen von Strace dienen dazu, die Ausgaben zu beschränken (siehe Tabelle “Wichtige Befehlszeilenoptionen von Strace”). Voreingestellt, also ohne diese Optionen, wirft das Tool alle Systemaufrufe aus, die das beobachtete Programm tätigt. Listing 1 zeigt einen typischen Strace-Aufruf. Als Resultat erhalten Sie dabei eine schier endlos scheinende Liste an dateibezogenen Systemaufrufen, die im Terminal erscheinen. Oft genügt das so Angezeigte schon für eine Diagnose, etwa wenn das Programm terminiert, weil es eine bestimmte Datei nicht findet oder diese nicht lesen kann. Das zeigen dann oft die letzten noch im Terminal vorhandenen Zeilen.

Einen typischen Fall demonstriert dabei die zweite Zeile von Listing 1, in der Sie den Fehlercode -1 ENOENT (No such file or directory) erkennen. Hier verlief der Versuch erfolglos, auf die Datei /etc/ld.so.preload zuzugreifen. In diesem Fall hatte das keine negativen Folgen, da das Programm damit umzugehen wusste und auf /etc/ld.so.cache auswich (dritte Zeile). Bei weniger fehlertolerant programmierter Software jedoch führt ein solcher Fehler regelmäßig schon zum Absturz.

$ strace -e file bash
execve("/usr/local/bin/bash", ["bash"], [/* 103 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
[...]
stat("/home/tst/.bash_history", {st_mode=S_IFREG|0600, st_size=16493, ...}) = 0
open("/home/tst/.bash_history", O_RDONLY) = 3

Rufen Sie es nur mit der Option -pPID auf, kann Strace feststellen, ob ein vermeintlich nicht mehr arbeitendes Programm tatsächlich keine Systemaufrufe mehr tätigt. Arbeitet es stattdessen aber hauptsächlich im RAM, weil es beispielsweise eine Datenbank durchsucht oder sortiert, zeigt Strace das an.

Detektivarbeit

Um einen Nutzen aus den von Strace generierten Ausgaben zu ziehen, müssen Sie etwas (aber oft nicht sehr viel) über die verwendeten Systemaufrufe wissen. Am schnellsten erfahren Sie mehr zu einem Aufruf, indem Sie mittels man dessen Manpage anzeigen lassen, also beispielsweise man 2 stat.

Mit der Option -e Ausdruck aufgerufen, zeigt Strace nur die dem angegebenen Ausdruck entsprechenden Systemaufrufe. Ein solcher Ausdruck weist folgenden Aufbau auf:

Qualifier=[!]Wert1[,Wert2, ...]

Das Ausrufezeichen interpretiert Strace dabei als Negation. Da die Bash dieses Zeichen normalerweise als Sonderzeichen auswertet, müssen Sie es mit einem Backslash maskieren. Als Qualifier erkennt Strace hier auch spezielle Schlüsselwörter, wie etwa file für Dateizugriffe, process für System-Calls des Prozessmanagements, network für Netzwerkzugriffe, signal für Signale und einige weitere, darunter trace (die Vorgabe), abbrev, verbose, raw, read und write. Das hilft, einigermaßen verständliche Befehlszeilen zu konstruieren, die die wesentlichen Features berücksichtigen und damit zielgenau wirken.

Die Ausgabe in eine externe Datei (-o Datei) hilft bei der Post-Mortem-Analyse. Da Strace eine normale Textdatei erzeugt, lässt diese sich gut mit dem Editor durchsuchen oder mittels Grep nach relevanten Zeilen durchforsten.

Eine gewisse Vorsicht sollten Sie bei den Fork-Optionen walten lassen: Sie erhöhen den Umfang der Strace-Ausgabe unter Umständen sehr stark, und oft ist nicht mehr klar, welcher Prozess die Ausgaben verursachte. Allerdings gibt es manchmal auch keine Alternative zu diesen Optionen. Durch Kombination der Optionen -ff und -o erzeugt Strace für jeden Kind-Prozess eine eigene Log-Datei des Namens Datei.PID. Dies hilft bei der Auswertung ungemein. Allerdings führt es im Hauptprozess zu Meldungen der Art <unfinished …> und … resumed, die sich nicht mehr ganz einfach zuordnen lassen [2].

Cliffhanger

Hängt ein Programm fest, ist es interessant herauszufinden, woran das nun im Detail liegt. Strace zeigt diesen Zustand wie in Listing 2 gezeigt an. Bei flock handelt es sich um eine Funktion, die eine geöffnete Datei mit einem “File Lock” markiert oder diese Marke entfernt. Um welche Datei es sich dabei handelt, verrät gegebenenfalls ein Aufruf von readlink. Dieses Programm erwartet als Argument einen Dateideskriptor, im Beispiel 5, der im /proc-Dateisystem unter der fraglichen PID vorhanden ist (Listing 3). Im besten Fall gibt Readlink dann die zugehörige Datei aus. Allerdings verbinden sich Sockets, Pipes und Ähnliches nicht immer über Dateideskriptoren mit den Programmen.

Das am Ende von Listing 2 ausgegebene LOCK_EX zeigt an, dass das Anlegen des exklusiven Deskriptors fehlschlägt. Dazu erläutert man 2 flock: Place an exclusive lock. Only one process may hold an exclusive lock for a given file at a given time. In diesem Fall blockiert also offensichtlich ein anderer Prozess die Ressource /dev/urandom, wie die Ausgabe von Readlink zeigt. Der Fehler liegt also gar nicht beim beobachteten Programm; der eigentliche Übeltäter lässt sich nun mittels lsof dingfest machen [3].

$ sudo strace -p 1227
Process 1227 attached - interrupt to quit
flock(5, LOCK_EX

$ readlink /proc/1227/fd/5
/dev/urandom

Fazit

Mit Strace haben Sie ein schnelles und einfach anzuwendendes Werkzeug an der Hand, das in vielen Fällen überraschend gute Ergebnisse zeigt [4]. Ohne Optionen oder nur mit -p aufgerufen, hilft es, Lebenszeichen von scheinbar hängenden Prozessen zu erhalten. Mit detaillierten Argumenten für die Option -e lassen sich zielgenau die gewünschten Informationen herausfiltern.