ps, pgrep und pkill im Detail: Prozesse gezielt finden und steuern

1. Jenseits von ps aux: individuelle Format-Optionen

ps aux ist der Standardaufruf, den fast jeder Admin reflexartig tippt, aber die feste Spaltenauswahl dieses Aufrufs ist selten optimal für eine konkrete Fragestellung. Über ps -eo lässt sich die Ausgabe frei zusammenstellen, mit exakt den Feldern, die für die aktuelle Diagnose relevant sind, von der Prozess-ID über Speicherverbrauch bis zur Startzeit.

Besonders nützlich ist die Kombination aus --sort und einer eigenen Feldliste, um beispielsweise die zehn Prozesse mit dem höchsten Speicherverbrauch auf einen Blick zu sehen, ohne die komplette Prozessliste manuell zu durchsuchen. Das spart bei einem akuten Speicherproblem auf einem Magento-Applikationsserver wertvolle Zeit gegenüber dem Scrollen durch eine unsortierte aux-Ausgabe.

# Eigene Feldliste: PID, Nutzer, CPU, RSS in MB, Startzeit, Kommando
ps -eo pid,user,pcpu,rss,lstart,cmd --sort=-rss | head -n 11

# Nur Prozesse eines bestimmten Nutzers, sortiert nach CPU-Last
ps -u www-data -o pid,pcpu,pmem,etime,cmd --sort=-pcpu

2. Thread-Details und Prozessbaum-Ansicht

Standardmäßig zeigt ps einen Prozess als eine einzige Zeile, auch wenn er intern aus mehreren Threads besteht. Mit dem Flag -L oder -T werden einzelne Threads als eigene Zeilen aufgelistet, was bei der Diagnose von Multithread-Anwendungen wie bestimmten Elasticsearch- oder Java-Prozessen hilft, um zu sehen, welcher konkrete Thread hohe CPU-Last verursacht.

Für die Eltern-Kind-Beziehung zwischen Prozessen liefert ps -ef --forest eine eingerückte Baumdarstellung, die auf einen Blick zeigt, welcher PHP-FPM-Master welche Worker gestartet hat oder welcher Cron-Job welchen Kindprozess erzeugt hat, deutlich übersichtlicher als eine flache Liste mit PPID-Spalte.

# Threads eines bestimmten Prozesses einzeln anzeigen
ps -L -p 28417 -o pid,tid,pcpu,comm

# Prozessbaum als eingerueckte Baumstruktur
ps -ef --forest | grep -A5 php-fpm

3. pgrep: Prozesse per Pattern-Matching finden

pgrep durchsucht die Prozessliste direkt nach Prozessnamen oder Kommandozeilen-Patterns und gibt passende PIDs zurück, ohne den Umweg über ps | grep und den damit verbundenen Zusatzprozess, der sich selbst im Ergebnis wiederfinden kann. Standardmäßig prüft pgrep nur den Prozessnamen, mit -f wird stattdessen die vollständige Kommandozeile gegen das Pattern geprüft.

Zusätzliche Filter wie -u für den Nutzer, -P für den Elternprozess und -x für einen exakten statt teilweisen Namensabgleich machen die Suche präzise. Gerade -x ist in der Praxis oft entscheidend, weil ohne diesen Schalter auch Prozesse gefunden werden, deren Name das Pattern nur als Teilstring enthält.

# PIDs aller php-fpm-Prozesse eines bestimmten Pools finden (volle Kommandozeile durchsuchen)
pgrep -f "php-fpm: pool magento-prod"

# Nur exakt "redis-server" als Prozessname, nicht z.B. "redis-server-old"
pgrep -x redis-server

# Prozesse eines bestimmten Nutzers mit Detailausgabe (Name + PID)
pgrep -u www-data -l

4. Namespace-Filter bei pgrep und pkill

Auf Hosts mit Containern oder mehreren PID-Namespaces, etwa bei Docker-Setups im Mark-Shust-Stil mit mehreren Magento-Instanzen, wird die Prozessliste des Hosts schnell unübersichtlich, weil Container-interne Prozesse und Host-Prozesse gemeinsam sichtbar sind. Neuere Versionen von pgrep und pkill unterstützen den Schalter --ns, um die Suche auf den Namespace eines Referenzprozesses zu beschränken.

Damit lässt sich gezielt nur innerhalb des PID-Namespace eines bestimmten Containers suchen, ohne versehentlich gleichnamige Prozesse in einem anderen Container oder auf dem Host selbst zu treffen. Ist --ns auf der jeweiligen Distribution nicht verfügbar, bleibt als Alternative der Umweg über nsenter in den Namespace des Zielcontainers.

# Referenz-PID eines Containers ermitteln
docker inspect --format '{{.State.Pid}}' magento-app-1

# Nur Prozesse im selben PID-Namespace wie dieser Referenzprozess suchen
pgrep --ns 48213 -l php-fpm

5. pkill und die Sicherheitsfallstricke zu grober Patterns

pkill nutzt dieselbe Pattern-Matching-Logik wie pgrep, sendet aber statt einer Liste von PIDs direkt ein Signal an alle Treffer, standardmäßig SIGTERM. Genau diese Kombination aus unscharfem Pattern und sofortiger Wirkung macht pkill zu einem der gefährlichsten Standardbefehle in der täglichen Administration.

Ein Klassiker unter den Fallstricken: pkill -f magento auf einem Host, der neben der Magento-Anwendung auch ein gleichnamiges Backup-Skript oder einen Log-Rotations-Cron mit 'magento' im Pfad ausführt, beendet ungewollt weit mehr Prozesse als beabsichtigt. Auf Multi-Tenant-Hosts mit mehreren Magento-Instanzen kann ein zu grobes Pattern sogar Prozesse einer völlig anderen Kundeninstallation treffen.

Die sichere Vorgehensweise ist immer zweistufig: Zunächst mit pgrep exakt dieselben Kriterien testen, die Ausgabe manuell prüfen, und erst danach mit pkill dasselbe Pattern anwenden. Zusätzlich sollte pkill mit dem sanfteren SIGTERM beginnen und erst bei ausbleibender Reaktion auf SIGKILL eskalieren, statt direkt mit -9 zu arbeiten.

# Erst testen: welche Prozesse würde das Pattern treffen?
pgrep -af "magento-prod-worker"

# Erst nach manueller Pruefung tatsaechlich beenden, sanft mit SIGTERM
pkill -f "magento-prod-worker"

# Nur eskalieren, wenn Prozesse nach kurzer Wartezeit weiterhin laufen
sleep 5 && pkill -9 -f "magento-prod-worker"

6. pkill mit präzisen Zusatzfiltern absichern

Um das Risiko eines zu breiten Treffers zu minimieren, lohnt sich die Kombination mehrerer Filter statt eines einzelnen, weit gefassten Patterns. -u beschränkt auf einen bestimmten Nutzer, -P auf Kindprozesse eines bekannten Elternprozesses, und --older beziehungsweise --newer filtert nach Prozessalter, was bei der gezielten Bereinigung hängengebliebener alter Worker hilfreich ist.

Für PHP-FPM-Pools speziell ist es meist sicherer, den Pool-Master über systemctl reload php8.4-fpm gezielt neu zu laden, statt einzelne Worker per pkill zu beenden, weil der Master dann selbst für einen sauberen, kontrollierten Ersatz der Worker sorgt, statt dass ein extern gesendetes Signal den internen Zustand des Pools durcheinanderbringt.

# Nur Prozesse eines bestimmten Nutzers UND aelter als 2 Stunden beenden
pkill -u www-data --older 7200 -f "worker.php"

# Kindprozesse eines bekannten Elternprozesses gezielt beenden
pkill -P 28400

7. Vergleich zu systemctl und journalctl bei systemd-Diensten

Für alle Prozesse, die als systemd-Dienst verwaltet werden, sind pgrep und pkill grundsätzlich das falsche Werkzeug für Kontrollaktionen. systemctl restart, systemctl reload und systemctl stop respektieren die im Unit-File definierte Stop-Sequenz, Timeout-Werte und eventuelle Abhängigkeiten zwischen Diensten, während ein rohes Signal per pkill all das umgeht.

Wird ein systemd-verwalteter Prozess per pkill beendet, interpretiert systemd das je nach Restart-Policy oft als unerwarteten Absturz und startet den Dienst automatisch neu, was zu verwirrenden, scheinbar grundlosen Neustarts führen kann. Für die reine Beobachtung bleibt pgrep weiterhin nützlich, für die eigentliche Kontrolle von systemd-Diensten gehört aber konsequent systemctl verwendet, ergänzt um journalctl -u <dienst> für die zugehörigen Logs statt manueller Prozess-Diagnose.

Der sinnvolle Einsatzbereich für pgrep und pkill bleibt damit auf Prozesse beschränkt, die nicht über systemd verwaltet werden, etwa manuell gestartete Skripte, Legacy-Cron-Jobs oder Debug-Sitzungen, bei denen kein Unit-File mit definiertem Lebenszyklus existiert.

# Richtig für systemd-verwaltete Dienste: kontrollierter Neustart
systemctl restart php8.4-fpm

# Zugehoerige Logs des Dienstes ansehen statt manueller Prozess-Suche
journalctl -u php8.4-fpm -n 100 --no-pager

8. Best Practices für den produktiven Einsatz

Vor jedem pkill-Aufruf gehört ein pgrep mit identischem Pattern zur Kontrolle dazu, ohne Ausnahme, auch unter Zeitdruck während eines Incidents. Patterns sollten so spezifisch wie möglich formuliert werden, im Zweifel lieber mit zusätzlichen Filtern wie -u oder -P kombiniert als mit einem einzelnen, weit gefassten Namensmuster zu arbeiten.

Für alles, was unter systemd läuft, gilt konsequent systemctl statt pkill, weil nur so die im Unit-File definierte Stop-Sequenz und eventuelle Dienstabhängigkeiten respektiert werden. ps -eo mit einer eigenen Feldliste ersetzt in den meisten Fällen mehrere aufeinanderfolgende ps aux | grep-Aufrufe und liefert von Anfang an genau die Information, die für die konkrete Diagnose gebraucht wird.

9. Kontinuierliche Beobachtung mit watch und pgrep kombinieren

Für die Beobachtung eines sich entwickelnden Problems, etwa eines PHP-FPM-Pools, der langsam immer mehr Speicher belegt, lohnt sich die Kombination aus watch und einem gezielten ps-Aufruf, statt den Befehl manuell alle paar Sekunden erneut einzutippen. So lässt sich in Echtzeit verfolgen, ob die Anzahl der Worker oder deren Speicherverbrauch tatsächlich stetig wächst.

Auch pgrep -c, das lediglich die Anzahl der Treffer statt der einzelnen PIDs zurückgibt, eignet sich gut für einfache Schwellenwert-Checks in Monitoring-Skripten, etwa um zu alarmieren, sobald die Anzahl laufender Worker eines Pools einen erwarteten Bereich verlässt, ohne dass dafür ein komplexeres Monitoring-Tool aufgesetzt werden muss.

Für eine einmalige, aber tiefere Momentaufnahme aller Prozesse eines bestimmten Nutzers samt vollständiger Kommandozeile bietet sich ps -u www-data -o pid,cmd --no-headers als Basis für weitere Skripte an, etwa um daraus automatisiert eine Liste an pgrep oder gezielte kill-Aufrufe abzuleiten, statt Rohdaten manuell weiterzuverarbeiten.

# Speicherverbrauch eines Pools alle 2 Sekunden live beobachten
watch -n 2 'ps -eo pid,rss,cmd | grep "pool magento-prod" | grep -v grep'

# Nur die Anzahl der Treffer für einen einfachen Schwellenwert-Check
pgrep -cf "pool magento-prod"

10. Zusammenfassung

11. FAQ: ps/pgrep/pkill