Das /proc Dateisystem erkunden: Kernel-Zustand ohne Zusatztools

1. Was das proc Dateisystem wirklich ist

Das proc Dateisystem, meist einfach /proc genannt, ist kein echtes Dateisystem auf einer Festplatte, sondern ein virtuelles Dateisystem, das der Kernel bei jedem Zugriff dynamisch generiert. Wenn ein Prozess /proc/1234/status liest, greift der Kernel nicht auf gespeicherte Daten zu, sondern erzeugt den Dateiinhalt in dem Moment, in dem gelesen wird, direkt aus seinen internen Datenstrukturen. Das macht das proc Dateisystem zu einer der zuverlaessigsten Informationsquellen fuer den Systemzustand, weil es niemals veraltet sein kann. Es zeigt immer den exakten Zustand des Kernels zum Zeitpunkt des Lesens.

Historisch wurde das proc Dateisystem eingefuehrt, um Prozessinformationen ohne spezielle Systemaufrufe zugaenglich zu machen, die klassische Unix-Tools wie ps vorher ueber direkten Speicherzugriff auf den Kernel realisieren mussten. Heute deckt /proc weit mehr ab als Prozesse: CPU-Informationen, Speichernutzung, Netzwerkverbindungen, geladene Kernel-Module und tausende Kernel-Parameter unter /proc/sys sind alle ueber dasselbe einheitliche Interface erreichbar. Wer versteht, wie das proc Dateisystem aufgebaut ist, versteht gleichzeitig, wie fast jedes Standard-Diagnosewerkzeug unter Linux intern funktioniert, denn fast alle lesen letztlich aus /proc.

2. /proc/[pid]: Prozessinformationen direkt aus dem Kernel

Fuer jeden laufenden Prozess legt der Kernel automatisch ein Verzeichnis unter /proc/[pid]/ an, wobei [pid] die Prozess-ID ist. Dieses Verzeichnis verschwindet, sobald der Prozess beendet wird, was es zu einer perfekten Live-Sicht auf laufende Prozesse macht. Innerhalb dieses Verzeichnisses liegen Dutzende Dateien und Unterverzeichnisse, die jeweils einen bestimmten Aspekt des Prozesses offenlegen: cmdline enthaelt die vollstaendige Kommandozeile, mit der der Prozess gestartet wurde, cwd ist ein Symlink auf das aktuelle Arbeitsverzeichnis, und fd/ listet jeden offenen Dateideskriptor als Symlink auf die zugehoerige Datei oder Socket.

Besonders nuetzlich im proc Dateisystem ist /proc/[pid]/environ, das die kompletten Umgebungsvariablen eines laufenden Prozesses zeigt, was bei der Diagnose von Konfigurationsproblemen in PHP-FPM- oder Nginx-Worker-Prozessen unschaetzbar ist. /proc/[pid]/maps zeigt die komplette Speicher-Mapping-Tabelle des Prozesses, inklusive aller geladenen Shared Libraries mit ihren Adressbereichen, was bei der Analyse von Speicherlecks oder Segmentation Faults hilft. Der Sonderfall /proc/self verweist immer auf den Prozess, der gerade selbst liest, unabhaengig von seiner tatsaechlichen PID.

# Full command line the process was started with (null-separated)
cat /proc/1234/cmdline | tr '\0' ' '; echo

# Current working directory of a running process
readlink /proc/1234/cwd

# List every open file descriptor as a symlink target
ls -la /proc/1234/fd/

# Full environment variables of a running process (root or same user)
sudo cat /proc/1234/environ | tr '\0' '\n'

# Memory mapping table: shared libraries and their address ranges
cat /proc/1234/maps | head -20

# /proc/self always refers to the process reading it
readlink /proc/self/exe

3. CPU und Speicher: /proc/cpuinfo und /proc/meminfo

/proc/cpuinfo ist die kanonische Quelle fuer detaillierte CPU-Informationen unter Linux und wird von praktisch jedem hoeheren Diagnosewerkzeug ausgelesen. Die Datei listet fuer jeden logischen Prozessorkern einen eigenen Block mit Modellname, Taktfrequenz, Cache-Groesse und den unterstuetzten CPU-Flags wie avx2 oder sse4_2, die entscheiden, ob bestimmte optimierte Code-Pfade in Anwendungen wie PHP-Opcache oder Datenbank-Engines ueberhaupt genutzt werden koennen. Die Anzahl der Bloecke entspricht der Anzahl logischer Kerne inklusive Hyperthreading, nicht der Anzahl physischer Kerne.

/proc/meminfo ist das Gegenstueck fuer den Arbeitsspeicher und liefert weit mehr Detail als free -h, das intern genau diese Datei parst. Zeilen wie MemAvailable zeigen den tatsaechlich fuer neue Anwendungen verfuegbaren Speicher inklusive reclaimable Caches, waehrend Dirty die Menge an Speicherseiten zeigt, die geaendert, aber noch nicht auf die Festplatte geschrieben wurden. Fuer Datenbankserver ist besonders Cached relevant, weil ein hoher Wert bedeutet, dass der Kernel viel Dateisystem-Cache haelt, was bei Bedarf sofort fuer Anwendungen freigegeben wird, keine verschwendete Ressource ist.

# Count logical CPU cores (includes hyperthreading)
grep -c ^processor /proc/cpuinfo

# Show model name and clock speed for each core
grep -E "model name|MHz" /proc/cpuinfo

# Check whether the CPU supports AVX2 (relevant for optimized code paths)
grep -o avx2 /proc/cpuinfo | head -1

# Key memory figures, same source free -h parses internally
grep -E "MemTotal|MemAvailable|Cached|Dirty|SwapTotal" /proc/meminfo

# Live memory monitoring without top or free
watch -n 1 'grep -E "MemAvailable|Cached" /proc/meminfo'

4. Prozessstatus im Detail: status, statm und cmdline

/proc/[pid]/status ist die menschenlesbare Zusammenfassung eines Prozesszustands und enthaelt Felder, die einzeln kaum ein anderes Tool so kompakt liefert: State zeigt den aktuellen Prozesszustand (laufend, schlafend, im unterbrechbaren oder nicht unterbrechbaren Wartezustand oder Zombie), VmRSS den tatsaechlich im physischen Speicher belegten Anteil, und Threads die Anzahl der Threads innerhalb des Prozesses. Fuer PHP-FPM-Worker ist VmRSS besonders wichtig, weil es den echten Speicherverbrauch pro Worker zeigt, im Gegensatz zu VmSize, das auch virtuellen, nicht zugewiesenen Adressraum mitzaehlt und daher oft ein Vielfaches des tatsaechlichen Verbrauchs zeigt.

Die Datei /proc/[pid]/statm liefert dieselben Speicherwerte als reine Zahlen in Speicherseiten statt als formatierten Text, was sie fuer Skripte und Monitoring-Agenten geeigneter macht als das textuelle status. Der Unterschied zwischen status und stat (ohne m): /proc/[pid]/stat ist eine einzelne Zeile mit space-getrennten Feldern in fester Reihenfolge, optimiert fuer maschinelles Parsen mit minimalem Overhead, waehrend status fuer Menschen lesbar formatiert ist. Beide Dateien beschreiben denselben Kernel-Zustand, nur mit unterschiedlicher Zielgruppe.

# Human-readable process status summary
cat /proc/1234/status | grep -E "State|VmRSS|VmSize|Threads"

# Real resident memory in kilobytes for a PHP-FPM worker
awk '/VmRSS/{print $2, $3}' /proc/1234/status

# Machine-parseable memory figures in pages (statm)
cat /proc/1234/statm

# Single-line stat file, fixed field order, minimal parsing overhead
cat /proc/1234/stat

# Sum resident memory of all php-fpm worker processes
for pid in $(pgrep php-fpm); do
  awk '/VmRSS/{sum+=$2} END{print sum " kB"}' /proc/"$pid"/status
done | awk '{s+=$1} END{print s " kB total"}'

5. Netzwerkstatus aus /proc/net auslesen

Das Unterverzeichnis /proc/net/ ist die Datenquelle, aus der klassische Tools wie netstat ihre Informationen beziehen, bevor modernere Alternativen wie ss auf die Netlink-Schnittstelle des Kernels umgestiegen sind. /proc/net/tcp und /proc/net/tcp6 listen jede aktive TCP-Verbindung mit lokaler und entfernter Adresse in hexadezimaler Notation, Verbindungsstatus als Hex-Code und der Inode-Nummer des zugehoerigen Sockets. Diese Inode-Nummer laesst sich mit den Eintraegen in /proc/[pid]/fd/ abgleichen, um herauszufinden, welcher Prozess eine bestimmte Verbindung haelt, ganz ohne lsof oder ss.

Fuer aggregierte Statistiken ist /proc/net/dev die zentrale Quelle: Es zeigt fuer jedes Netzwerkinterface kumulierte Byte- und Paketzaehler fuer eingehenden und ausgehenden Verkehr seit dem letzten Boot, inklusive Fehler- und Drop-Zaehler. Ein staendig steigender Drop-Zaehler auf einem produktiven Interface deutet meist auf ueberlastete Ring-Buffer oder eine zu kleine Empfangswarteschlange hin, ein klassisches Signal fuer notwendiges Netzwerk-Tuning. Das proc Dateisystem macht diese Rohzahlen zugaenglich, ohne dass ein separates Monitoring-Tool installiert werden muss.

# Active TCP connections in raw kernel format (hex addresses, hex state)
cat /proc/net/tcp | head -5

# Cumulative interface statistics since last boot
cat /proc/net/dev

# Watch for a rising error/drop counter, a sign of NIC or buffer pressure
watch -n 2 'cat /proc/net/dev | grep eth0'

# Match a socket inode from /proc/net/tcp to the owning process
# 1. Find the inode for a connection in /proc/net/tcp
# 2. Grep for that inode across all /proc/[pid]/fd/ symlinks
for pid in /proc/[0-9]*; do
  ls -la "$pid"/fd 2>/dev/null | grep -q "socket:\[12345\]" && echo "$pid"
done

6. /proc/sys: die sysctl-Schnittstelle des Kernels

Das Verzeichnis /proc/sys/ ist die direkte Schnittstelle zu tausenden Kernel-Parametern, die haeufig ueber das Kommandozeilenwerkzeug sysctl verwaltet werden. Tatsaechlich ist sysctl nur eine bequeme Huelle um genau dieselben Dateien, die auch direkt gelesen und geschrieben werden koennen. Der Parameter net.ipv4.ip_forward etwa entspricht der Datei /proc/sys/net/ipv4/ip_forward, und beide Zugriffswege veraendern denselben Kernel-Zustand ohne Unterschied im Ergebnis. Jeder Punkt im sysctl-Namen entspricht einer Verzeichnisebene im Pfad unter /proc/sys.

Der direkte Zugriff ueber das proc Dateisystem ist besonders in minimalen Container-Umgebungen relevant, in denen sysctl nicht installiert ist, aber /proc immer verfuegbar bleibt, solange es nicht explizit maskiert wurde. Aenderungen ueber echo wert > /proc/sys/pfad gelten sofort und wirken identisch zu sysctl -w, sind aber wie alle direkten sysctl-Aenderungen nicht ueber einen Neustart persistent. Fuer dauerhafte Aenderungen bleibt /etc/sysctl.d/ der richtige Ort, das proc Dateisystem zeigt aber jederzeit den tatsaechlich aktiven Wert, unabhaengig davon, was in einer Konfigurationsdatei steht.

# Read a kernel parameter directly, equivalent to sysctl net.ipv4.ip_forward
cat /proc/sys/net/ipv4/ip_forward

# Same value via sysctl, just a convenient wrapper around the same file
sysctl net.ipv4.ip_forward

# Write directly, takes effect immediately, not persistent across reboot
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# Every dot in a sysctl name is a directory level under /proc/sys
ls /proc/sys/net/ipv4/ | grep tcp_

# Find every writable tunable under a given subsystem
find /proc/sys/vm -type f

7. Dateideskriptoren und Limits ueber /proc nachvollziehen

Ein haeufiges Produktionsproblem ist das Erreichen der maximalen Anzahl offener Dateideskriptoren, was Anwendungen mit der Fehlermeldung Too many open files abstuerzen laesst. Das proc Dateisystem macht diesen Zustand direkt sichtbar: /proc/[pid]/limits zeigt sowohl das Soft- als auch das Hard-Limit fuer jede Ressourcenart eines konkreten Prozesses, waehrend ls /proc/[pid]/fd/ | wc -l die aktuell tatsaechlich genutzte Anzahl liefert. Naehert sich dieser Wert dem Limit aus limits, ist ein Absturz durch Ressourcenerschoepfung nur eine Frage der Zeit.

Systemweit zeigt /proc/sys/fs/file-nr drei Werte in einer Zeile: die Anzahl aktuell zugewiesener Dateideskriptoren, die Anzahl freier, aktuell nicht genutzter, und das systemweite Maximum aus /proc/sys/fs/file-max. Diese systemweite Grenze ist unabhaengig von den Pro-Prozess-Limits aus ulimit und betrifft alle Prozesse gemeinsam. Auf stark ausgelasteten Datenbank- oder Webservern mit vielen gleichzeitigen Verbindungen ist ein regelmaessiger Blick in beide Ebenen, Pro-Prozess und systemweit, Teil einer soliden Kapazitaetsplanung.

# Soft and hard limits for a specific running process
cat /proc/1234/limits | grep -i "open files"

# Currently open file descriptors for that same process
ls /proc/1234/fd/ | wc -l

# System-wide: allocated, free, and maximum file descriptors
cat /proc/sys/fs/file-nr

# System-wide hard ceiling for all processes combined
cat /proc/sys/fs/file-max

# Find the process closest to exhausting its own file descriptor limit
for pid in /proc/[0-9]*; do
  p=$(basename "$pid")
  used=$(ls "$pid"/fd 2>/dev/null | wc -l)
  max=$(awk '/Max open files/{print $4}' "$pid"/limits 2>/dev/null)
  [ -n "$max" ] && [ "$used" -gt 0 ] && echo "$p: $used/$max"
done | sort -t/ -k1 -rn | head -5

8. proc Dateisystem in eigenen Skripten nutzen

Weil das proc Dateisystem aus reinen Textdateien besteht, laesst es sich ohne Bibliotheken oder API-Aufrufe direkt aus Bash, PHP oder Python auslesen, was es zur idealen Grundlage fuer leichte, abhaengigkeitsfreie Monitoring-Skripte macht. Ein Healthcheck-Skript, das prueft, ob ein PHP-FPM-Master-Prozess laeuft und wie viel Speicher er belegt, braucht keine externe Bibliothek, sondern liest einfach /proc/[pid]/status ein und parst die relevanten Felder mit awk oder grep.

Wichtig fuer robuste Skripte: Zwischen dem Auflisten eines Prozessverzeichnisses und dem Lesen einer Datei darin kann der Prozess beendet worden sein, was zu einem No such file or directory-Fehler fuehrt. Produktive Skripte, die das proc Dateisystem systematisch durchsuchen, muessen diesen Fall abfangen, etwa mit 2>/dev/null und einer Pruefung auf leere Ausgabe, statt das Skript bei einem einzelnen verschwundenen Prozess abbrechen zu lassen. Diese Race Condition ist normal und erwartbar, kein Zeichen eines Fehlers im Skript selbst.

#!/usr/bin/env bash
# Minimal healthcheck script using only /proc, no external dependencies
set -euo pipefail

check_process_memory() {
  local pid="$1"
  local max_mb="$2"
  # Handle the race: process may vanish between listing and reading
  local rss_kb
  rss_kb=$(awk '/VmRSS/{print $2}' /proc/"$pid"/status 2>/dev/null) || return 1
  [ -z "$rss_kb" ] && return 1

  local rss_mb=$((rss_kb / 1024))
  if (( rss_mb > max_mb )); then
    echo "[WARN] PID $pid uses ${rss_mb}MB (limit: ${max_mb}MB)"
    return 1
  fi
  return 0
}

for pid in $(pgrep php-fpm); do
  check_process_memory "$pid" 256 || echo "  -> investigate $pid"
done

9. proc Dateisystem im Vergleich zu klassischen Tools

Fast jedes klassische Diagnosewerkzeug unter Linux ist letztlich nur eine formatierte Ansicht auf Dateien im proc Dateisystem. Der direkte Zugriff auf /proc lohnt sich, wenn ein Tool fehlt, wenn Rohdaten fuer Skripte gebraucht werden oder wenn man exakt verstehen will, woher eine Zahl stammt.

Der praktische Nutzen des proc Dateisystems zeigt sich vor allem in minimalen Container-Images ohne Diagnose-Pakete, in Monitoring-Agenten, die keine externen Prozesse starten sollen, und beim Debugging, wenn verstanden werden muss, woher eine Zahl in einem hoeheren Tool eigentlich stammt. Fast jede Metrik, die Monitoring-Systeme wie Prometheus Node Exporter sammeln, stammt letztlich aus genau diesen Dateien unter /proc.

10. Zusammenfassung

Das proc Dateisystem ist die vielleicht unterschaetzteste Diagnosequelle unter Linux, weil fast jedes Standardtool letztlich nur eine formatierte Ansicht genau dieser virtuellen Dateien ist. /proc/[pid]/ liefert vollstaendige Prozessinformationen inklusive Kommandozeile, Umgebungsvariablen und Speicher-Mapping. /proc/cpuinfo und /proc/meminfo zeigen Hardware- und Speicherzustand in maximaler Detailtiefe. /proc/net/ macht Verbindungen und Interface-Statistiken zugaenglich, und /proc/sys/ ist die direkte, ungefilterte Schnittstelle zu jedem sysctl-Parameter des Kernels.

Der groesste praktische Wert des proc Dateisystems liegt in seiner Universalitaet: Es funktioniert in jedem Container, auf jeder Distribution und ohne ein einziges Zusatzpaket, weil es Teil des Kernels selbst ist. Wer eigene Monitoring- oder Healthcheck-Skripte schreibt, spart durch direkten /proc-Zugriff externe Abhaengigkeiten und versteht gleichzeitig genauer, welche Kernel-Zustaende hinter jeder angezeigten Metrik stecken.

11. FAQ: Das proc Dateisystem erkunden