strace: Systemaufrufe von Prozessen live debuggen

1. Was strace eigentlich sichtbar macht

strace klinkt sich über die ptrace-Schnittstelle des Kernels in einen Prozess ein und protokolliert jeden Systemaufruf, den dieser Prozess tätigt, zusammen mit den übergebenen Argumenten, dem Rückgabewert und, falls der Aufruf fehlschlägt, dem passenden errno-Wert. Damit liegt eine Ebene offen, die für die Anwendung selbst meist unsichtbar bleibt: Jede Datei, die geöffnet wird, jeder Socket, der verbunden wird, jedes Signal, das eintrifft.

Für einen Magento-Hosting-Kontext ist das besonders wertvoll, weil ein Großteil der tatsächlichen Probleme, hängende PHP-FPM-Worker, verweigerte Dateizugriffe durch falsche Berechtigungen, blockierende Netzwerkverbindungen zu Redis oder Elasticsearch, sich exakt auf Ebene der Systemaufrufe manifestiert, lange bevor sie in einem Anwendungslog auftauchen, wenn sie dort überhaupt jemals auftauchen.

2. An einen bereits laufenden Prozess anhängen

Der häufigste Anwendungsfall in der Produktion ist nicht das Starten eines neuen Prozesses unter strace, sondern das nachträgliche Anhängen an einen bereits laufenden Prozess über die PID mit dem Flag -p. Das ist entscheidend, wenn ein PHP-FPM-Worker bereits seit Minuten hängt und der Neustart des gesamten Pools den Fehler nur verschleiern, aber nicht diagnostizieren würde.

Beim Anhängen unterbricht strace den Prozess kurz, um sich einzuklinken, danach läuft der Prozess normal weiter, nur eben beobachtet. Für mehrere Worker gleichzeitig lässt sich -f mit einer Prozessgruppe kombinieren, sodass auch Kindprozesse automatisch mitverfolgt werden, was bei PHP-FPM mit seinem Master-Worker-Modell fast immer notwendig ist.

# PID des hängenden PHP-FPM-Workers ermitteln
ps aux | grep php-fpm

# An den laufenden Prozess anhängen, Ausgabe in Datei mit Zeitstempeln
strace -p 28417 -tt -o /var/log/strace-fpm-worker.log

# Mehrere Threads/Kindprozesse desselben Prozesses gleichzeitig verfolgen
strace -f -p 28417 -tt

3. Fallbeispiel: Den hängenden PHP-FPM-Worker diagnostizieren

Ein klassisches Symptom: Ein FPM-Worker zeigt in ps weiterhin Rechenzeit, reagiert aber nicht mehr auf neue Requests. strace zeigt in solchen Fällen fast immer den letzten Syscall, in dem der Prozess blockiert, etwa ein read auf einen Socket, der nie eine Antwort liefert, oder ein flock, das auf eine bereits gehaltene Datei-Sperre wartet.

Bleibt die Ausgabe nach dem Anhängen komplett aus, ohne dass ein neuer Syscall protokolliert wird, ist der Prozess bereits in genau diesem Zustand hängen geblieben, bevor strace überhaupt gestartet wurde. Das allein ist schon eine wichtige Diagnose: Der Prozess wartet nicht auf CPU-Zeit, sondern blockiert in einem einzigen Systemaufruf, meist Netzwerk-I/O oder ein Locking-Mechanismus im Dateisystem.

# Anhängen und beobachten, ob überhaupt noch neue Syscalls auftauchen
strace -p 28417 -tt

# Typische Ausgabe bei blockierendem Redis-Aufruf:
# 14:22:01.120441 read(11, ...) = ... (dauert, kein Return)
#
# Wird nach mehreren Sekunden kein weiterer Syscall protokolliert,
# haengt der Prozess exakt in diesem read() Aufruf fest

4. Einen neuen Prozess direkt unter strace starten

Neben dem Anhängen an laufende Prozesse lässt sich strace auch direkt vor ein Kommando setzen, um einen neuen Prozess von Anfang an zu beobachten. Das eignet sich besonders für kurzlebige Kommandozeilen-Skripte, Cron-Jobs oder CLI-Aufrufe von Magento, bei denen der Fehler reproduzierbar auftritt.

Für PHP-CLI-Skripte, die etwa in einem Cron-Job fehlschlagen, liefert dieser Ansatz oft die vollständige Erklärung: Ein fehlendes Verzeichnis, eine falsche Umgebungsvariable oder eine nicht erreichbare Konfigurationsdatei zeigt sich unmittelbar als fehlgeschlagener openat-Aufruf mit ENOENT als Rückgabewert.

# Neuen Prozess direkt unter strace starten
strace -f -o /tmp/cron-debug.log php bin/magento indexer:reindex

# Nur Datei-bezogene Syscalls anzeigen, um fehlende Pfade zu finden
strace -f -e trace=open,openat,stat,access php bin/magento cache:flush

5. Fehlgeschlagene Datei-Zugriffe gezielt aufspüren

Berechtigungsprobleme gehören zu den häufigsten, aber am schwersten zu lokalisierenden Fehlern in gewachsenen Magento-Installationen. Statt Verzeichnis für Verzeichnis manuell zu prüfen, filtert man mit -e trace= gezielt auf datei-bezogene Syscalls und liest aus der Ausgabe direkt ab, welcher Pfad mit welchem Fehlercode scheitert.

Besonders aufschlussreich ist die Kombination aus -e trace=file, das alle datei-bezogenen Aufrufe wie openat, stat, unlink und chmod zusammenfasst, mit -Z, das ausschließlich fehlgeschlagene Aufrufe anzeigt. Dadurch verschwindet das Rauschen erfolgreicher Aufrufe komplett und nur die tatsächlichen Fehler bleiben sichtbar.

# Nur fehlgeschlagene, datei-bezogene Systemaufrufe anzeigen
strace -f -e trace=file -Z -p 28417

# Beispielausgabe bei fehlender Schreibberechtigung:
# openat(AT_FDCWD, "/var/www/html/var/cache/lock", O_CREAT|O_WRONLY) = -1 EACCES (Permission denied)

6. Filtern nach Syscall-Kategorien für gezielte Analysen

Neben der reinen Datei-Filterung kennt strace vordefinierte Syscall-Gruppen wie network, signal, ipc und process, die sich über -e trace= gezielt einschalten lassen. Für Netzwerkprobleme mit externen Diensten wie Elasticsearch oder Redis liefert -e trace=network ausschließlich Verbindungsaufbau, Datenübertragung und Verbindungsabbruch, ohne die Menge an Datei-Syscalls, die ein PHP-Prozess parallel dazu erzeugt.

Zusätzlich lässt sich die Ausgabe mit -c in eine statistische Zusammenfassung verwandeln, die pro Syscall-Typ Häufigkeit und kumulierte Zeit anzeigt. Das ist der schnellste Weg, um herauszufinden, ob ein Prozess seine Zeit überwiegend mit Datei-I/O, Netzwerk-I/O oder Speicherverwaltung verbringt, bevor man tiefer in einzelne Aufrufe einsteigt.

# Nur Netzwerk-Syscalls verfolgen, etwa für Redis-/Elasticsearch-Verbindungen
strace -f -e trace=network -p 28417

# Statistische Zusammenfassung über 5 Sekunden Laufzeit
timeout 5 strace -c -p 28417

7. Performance-Overhead und Einsatz in Produktion

strace ist kein Werkzeug für den Dauerbetrieb: Da jeder Systemaufruf den beobachteten Prozess anhält, an strace übergibt und danach fortsetzt, kann der Overhead je nach Syscall-Rate den Prozess um den Faktor zwei bis mehrere hundert verlangsamen. Für einen einzelnen hängenden Worker in einem Notfall ist das meist akzeptabel, für einen gesamten produktiven FPM-Pool unter Last aber nicht.

In der Praxis bedeutet das: strace gezielt an einzelnen, bereits auffälligen Prozessen einsetzen, die Beobachtungszeit möglichst kurz halten und im Zweifel mit timeout begrenzen. Für breitere, dauerhafte Beobachtung eines gesamten Systems ist strace grundsätzlich das falsche Werkzeug, dafür eignen sich Kernel-native Tracing-Mechanismen deutlich besser.

# Beobachtungszeit bewusst begrenzen, um Overhead zu minimieren
timeout 10 strace -p 28417 -tt -o /tmp/kurzcheck.log

# Anzahl der Syscalls pro Sekunde grob abschaetzen, um den Overhead einzuschaetzen
strace -c -f -p 28417 &
sleep 5
kill %1

8. Wann ltrace oder perf die bessere Wahl sind

strace zeigt ausschließlich Kernel-Grenzübertritte, also Systemaufrufe. Wenn der Verdacht eher bei Bibliotheksfunktionen liegt, etwa einer bestimmten OpenSSL- oder libc-Funktion, die sich seltsam verhält, aber keinen eigenen Syscall auslöst, liefert ltrace die passendere Sicht, weil es Aufrufe von dynamisch gelinkten Bibliotheksfunktionen protokolliert statt Kernel-Aufrufe.

Für Performance-Fragen jenseits einzelner blockierender Aufrufe, etwa warum ein Prozess insgesamt viel CPU-Zeit verbraucht, ist perf das deutlich passendere Werkzeug, weil es mit statistischem Sampling arbeitet und dadurch einen Bruchteil des Overheads von strace verursacht. strace beantwortet die Frage 'Woran hängt dieser eine Prozess gerade fest', perf beantwortet eher die Frage 'Wo verbringt dieser Prozess insgesamt seine Zeit'.

Für tieferes, systemweites Tracing ohne den Overhead von ptrace bieten sich zudem eBPF-basierte Werkzeuge wie bpftrace an, die Syscall-Ereignisse direkt im Kernel auswerten, statt jeden Aufruf über einen Kontextwechsel an ein Userspace-Programm zu reichen.

9. Best Practices für den produktiven Einsatz

Immer mit möglichst engem Syscall-Filter arbeiten, statt pauschal alles zu protokollieren: Das reduziert sowohl den Overhead als auch die Menge an Daten, die anschließend durchsucht werden muss. Zeitstempel mit -tt sind Pflicht, sobald es um zeitliche Zusammenhänge geht, etwa um festzustellen, wie lange ein bestimmter Aufruf tatsächlich blockiert hat.

Die Ausgabe grundsätzlich in eine Datei mit -o umleiten statt auf dem Terminal mitzulesen, besonders bei -f mit vielen Kindprozessen, weil die Ausgabemenge sonst schnell unübersichtlich wird. Nach der Diagnose gehört strace konsequent wieder abgeschaltet, ein vergessener strace-Prozess im Hintergrund bleibt ein unnötiger, dauerhafter Performance-Overhead auf dem Server.

10. Zusammenfassung

11. FAQ: strace