/proc ist ein vom Kernel bereitgestelltes Pseudo-Dateisystem (procfs) — keine echten Dateien auf der Disk, sondern eine textuelle Sicht auf den aktuellen Kernel-Zustand. Beim Lesen fragt der Kernel den Wert live ab; manche Einträge sind sogar schreibbar und konfigurieren den Kernel zur Laufzeit. Klassische Tools wie top, ps, free, uptime und lsof sind im Wesentlichen formatierte Frontends für /proc.

Was ist procfs?

procfs ist eines von mehreren Pseudo-Filesystemen im Linux-Kernel. Es belegt keinen Platz auf einer Disk, sondern wird vom Kernel beim Boot unter /proc gemountet:

Bash procfs als Mount sichtbar machen
mount | grep proc
# proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)

# Größe? Null Bytes — Daten kommen erst beim Lesen
df -h /proc
# proc       0      0     0    - /proc

# Inhalt von /proc auf einen Blick
ls /proc | head -20
# 1            consoles    iomem
# 1042         cpuinfo     ioports
# 142          crypto      kallsyms
# acpi         devices     keys
# buddyinfo    diskstats   kmsg
# ...

Was du in /proc findest, lässt sich in zwei Kategorien teilen:

  1. Pro-Prozess-Verzeichnisse (/proc/<PID>/) — pro laufendem Prozess ein Unterordner mit allen Informationen über diesen Prozess.
  2. System-weite Informationen als einzelne Dateien: /proc/cpuinfo, /proc/meminfo, /proc/mounts, /proc/net/, /proc/sys/ — die Kernel-Zustände und -Parameter abbilden.

Die Schnittstelle ist textuell: jede Datei lässt sich mit cat lesen, viele mit echo > ... schreiben. Das macht den Linux-Kernel introspektiv zugänglich, ohne spezielle APIs.

Pro-Prozess-Verzeichnisse

Für jeden laufenden Prozess existiert /proc/<PID>/ mit einer kompletten Sicht auf seinen Zustand. Die wichtigsten Einträge:

PfadInhalt
/proc/<PID>/cmdlineAufrufzeile (NUL-getrennte Argumente)
/proc/<PID>/commProgramm-Name (gekürzt auf 16 Zeichen)
/proc/<PID>/statusLesbarer Statusbericht (RSS, VmSize, UID, GID, …)
/proc/<PID>/statMaschinen-lesbare Status-Werte (für ps, top)
/proc/<PID>/fd/Symlinks auf alle geöffneten File-Descriptors
/proc/<PID>/mapsMemory-Layout: welche Dateien wohin in RAM gemappt sind
/proc/<PID>/environUmgebungsvariablen (NUL-getrennt)
/proc/<PID>/exeSymlink auf das ausgeführte Binary
/proc/<PID>/cwdSymlink aufs aktuelle Arbeitsverzeichnis
/proc/<PID>/rootSymlink aufs Wurzel-Verzeichnis (relevant bei chroot)
/proc/<PID>/limitsResource-Limits (ulimit)
/proc/<PID>/ioI/O-Statistiken (Bytes gelesen / geschrieben)
/proc/<PID>/net/Pro-Prozess Netzwerk-Statistik (im Netzwerk-Namespace)
/proc/<PID>/task/<TID>/Pro-Thread-Verzeichnis (jeder Thread hat eigene TID)
Bash Eigenen Shell-Prozess inspizieren
# $$ ist die PID der aktuellen Shell
echo "Meine Shell-PID ist $$"

# Speicher-Verbrauch
grep -E '^(VmRSS|VmSize|VmPeak)' /proc/$$/status

# Mit welchen Argumenten wurde sie gestartet?
tr '\0' ' ' < /proc/$$/cmdline; echo

# Welche Dateien hat sie offen?
ls -la /proc/$$/fd/

# Welche Bibliotheken sind gemappt?
head /proc/$$/maps

# Resource-Limits
cat /proc/$$/limits

Pro-Prozess-Daten gehören dem User des Prozesses und sind nur dem Owner und root vollständig lesbar — /proc/<andere-PID>/environ ist für Fremde versperrt, weil dort z. B. Passwörter aus Environment-Variablen stehen könnten.

System-weite Informationen

Außerhalb der Pro-Prozess-Ordner liegen die globalen Status-Dateien — die Werkzeuge top, free, vmstat, lsmod lesen alle aus diesen Quellen:

DateiInhalt
/proc/cpuinfoCPU-Modell, Cores, Cache, Flags pro Core
/proc/meminfoSpeicher-Statistik (Total, Free, Available, Buffers, Cached)
/proc/loadavg1/5/15-Minuten-Load-Averages und aktive/Total-Prozesse
/proc/uptimeUptime und idle time in Sekunden
/proc/statCPU-Auslastung, Context-Switches, Forks (vmstat-Quelle)
/proc/diskstatsI/O-Statistiken pro Device
/proc/mountsAktuell eingehängte Filesysteme (für mount ohne Argumente)
/proc/swapsAktive Swap-Bereiche
/proc/modulesGeladene Kernel-Module (für lsmod)
/proc/cmdlineBoot-Parameter, mit denen der Kernel gestartet wurde
/proc/versionKernel-Version, Compiler, Build-Datum
/proc/interruptsInterrupt-Statistik pro IRQ und CPU
/proc/net/Netzwerk-Stack-Statistiken
/proc/scsi/, /proc/iomemHardware-Mapping
Bash Kernel-Boot-Parameter und CPU-Modell ablesen
cat /proc/cmdline
# BOOT_IMAGE=/vmlinuz-6.10.0-generic root=UUID=... ro quiet splash

cat /proc/version
# Linux version 6.10.0-generic (buildd@...) (gcc 13.2.0) ...

# CPU-Modell und Anzahl Cores
grep '^model name' /proc/cpuinfo | uniq -c
# 16 model name : AMD Ryzen 9 7950X 16-Core Processor

# RAM und Swap
grep -E '^(MemTotal|MemAvailable|SwapTotal)' /proc/meminfo

/proc/net/ enthält besonders interessante Tabellen wie tcp, udp, unix, dev, route. ss, netstat, ip route lesen daraus.

/proc/sys und sysctl: Kernel zur Laufzeit konfigurieren

Unter /proc/sys/ finden sich Hunderte von schreibbaren Kernel-Parametern, mit denen sich der Kernel zur Laufzeit anpassen lässt: Netzwerk-Stack-Verhalten, Memory-Management, Filesystem-Limits, Sicherheits-Features.

Alles, was sysctl liest und schreibt, liegt physikalisch unter /proc/sys/ — die Tools sysctl und echo > /proc/sys/... sind funktionsgleich:

Bash Kernel-Parameter zur Laufzeit ändern
# Aktuellen Wert lesen
cat /proc/sys/net/ipv4/ip_forward
# 0
sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

# Wert setzen — beide Wege identisch
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo sysctl -w net.ipv4.ip_forward=1

# Persistent in /etc/sysctl.conf oder /etc/sysctl.d/*.conf
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/90-router.conf
sudo sysctl --system            # alle .conf neu einlesen

Häufig genutzte Parameter:

ParameterZweck
net.ipv4.ip_forwardIP-Forwarding aktivieren (Router/NAT)
net.ipv4.tcp_syncookiesSYN-Flood-Schutz aktivieren
net.ipv4.tcp_fin_timeoutTIME_WAIT-Verhalten — relevant für Hochlast-Server
net.core.somaxconnMax. Backlog-Queue für Listen-Sockets
vm.swappinessWie aggressiv der Kernel swappt (0–100)
vm.overcommit_memoryMemory-Overcommit-Strategie
fs.file-maxSystem-weites Limit für offene Dateien
kernel.pid_maxMaximale PID — wichtig auf Containerhost mit vielen Prozessen
kernel.dmesg_restrictBeschränkt dmesg-Lesen auf root

Die vollständige Liste füllt mehrere Manpages (man 7 sysctl, man 5 sysctl.conf, plus die kernel-Doku unter /usr/share/doc/kernel-*). Für die meisten Anwendungen reichen die Defaults — Tuning ist nur bei sehr spezifischen Workloads nötig.

Praxis: Was läuft auf meinem System?

/proc ist die Quelle aller laufzeitorientierten Diagnose-Werkzeuge. Direkter Zugriff hilft beim schnellen Debugging — vor allem auf Systemen, auf denen top, htop oder andere Tools fehlen (Container, Recovery-Modus).

Bash Top-10 Speicher-Fresser ohne ps oder top
# Prozesse nach RSS sortieren — direkt aus /proc/<PID>/status
for pid in /proc/[0-9]*; do
    rss=$(awk '/^VmRSS:/ { print $2 }' "$pid/status" 2>/dev/null)
    cmd=$(tr '\0' ' ' < "$pid/cmdline" 2>/dev/null | cut -c1-60)
    [ -n "$rss" ] && [ -n "$cmd" ] && echo "$rss ${pid##*/} $cmd"
done | sort -rn | head -10
Bash Welche Datei hat dieser Prozess offen?
# /proc/<PID>/fd/ enthält Symlinks pro File-Descriptor
ls -la /proc/$(pidof nginx | head -c 5)/fd/
# lrwx... 0 -> /dev/null
# lrwx... 1 -> /var/log/nginx/access.log
# lrwx... 2 -> /var/log/nginx/error.log
# lrwx... 3 -> 'socket:[12345]'

# Welche Dateien hat irgendein Prozess offen, die "deleted" sind?
# (z. B. wenn Logs gelöscht wurden, aber der Prozess sie noch hält)
sudo find /proc/*/fd -ls 2>/dev/null | grep '(deleted)'
Bash Memory-Map eines Prozesses
# /proc/<PID>/maps zeigt jeden gemappten Bereich
head -10 /proc/$(pidof firefox | head -c 5)/maps
# 55a8b9b00000-55a8b9b01000 r--p 00000000 fd:01 1234567 /usr/lib/firefox/firefox
# 55a8b9b01000-55a8b9d44000 r-xp 00001000 fd:01 1234567 /usr/lib/firefox/firefox
# ...

# smaps_rollup: Aggregierter Speicherverbrauch
cat /proc/$(pidof firefox | head -c 5)/smaps_rollup
# Rss:           4521840 kB
# Pss:           3819276 kB
# ...

Container und /proc

In Linux-Containern (Docker, podman, LXC) ist /proc standardmäßig sichtbar, aber mit Einschränkungen:

  • Container sehen nur die Prozesse aus ihrem PID-Namespace — nicht den Host.
  • System-weite Werte wie /proc/cpuinfo zeigen die Host-CPU, nicht limits via cgroups. Tools wie nproc müssen daher cgroup-aware sein, sonst sehen sie zu viele CPUs.
  • /proc/sys/ ist im Container größtenteils read-only (Sicherheits-Default).

Tools wie lxcfs (LXC) oder docker --pid=host können dieses Verhalten ändern, sind aber Spezial-Setups.

Bash In einem Container — was ist anders?
# Im Container: nur die eigenen Prozesse
docker run --rm alpine ls /proc | grep -E '^[0-9]+' | wc -l
# 2 (PID 1 und der ls-Prozess)

# Auf dem Host: alle Prozesse
ls /proc | grep -E '^[0-9]+' | wc -l
# 850

# cgroup-Memory-Limit eines Container-Prozesses
cat /proc/<PID>/cgroup
# 0::/system.slice/docker-abc123.scope

Interessantes

/proc-Dateien sind keine echten Dateien — Größe ist immer 0

ls -l /proc/cpuinfo zeigt 0 Bytes, cat liefert trotzdem Inhalt. Das verwirrt Skripte, die per stat die Größe prüfen, bevor sie lesen. Auch: /proc/<PID>/-Verzeichnisse können verschwinden, sobald der Prozess endet — Skripte, die sie iterieren, brauchen Fehlertoleranz für „No such file or directory".

Schreiben in /proc/sys ist nicht persistent

echo 1 > /proc/sys/... wirkt sofort, ist aber beim nächsten Reboot weg. Persistente Konfiguration gehört in /etc/sysctl.conf oder besser in eine eigene Drop-In-Datei unter /etc/sysctl.d/. Ohne sudo sysctl --system (oder Reboot) sieht der Kernel den neuen Default aber nicht.

/proc//exe ist auch nach Löschen des Binaries gültig

Wer ein Binary updated und das laufende Programm nicht neu startet, kann über /proc/<PID>/exe immer noch auf die alte (gelöschte) Version zugreifen. Praktisch für „Process running from deleted file"-Diagnose: lsof | grep deleted zeigt diese Fälle.

kernel.dmesg_restrict ist der Hardening-Default

Auf modernen Distributionen ist kernel.dmesg_restrict = 1 gesetzt: nur root darf dmesg aufrufen, der Kernel-Log ist für normale User nicht sichtbar. Das verhindert, dass Angreifer aus Pointern in Stack-Traces ASLR umgehen — kostet im Alltag aber wenig Komfort.

/proc ist für Container fast immer falsch — sysfs zunehmend richtiger

Für moderne Kernel-Konfiguration ist /sys (sysfs) der bessere Ort als /proc/sys. procfs ist historisch gewachsen, sysfs hat eine sauberere Struktur (siehe Artikel zu /sys). Kernel-Entwickler legen heute bevorzugt in /sys ab, nicht mehr in /proc.

lsof, fuser und htop sind /proc-Frontends

Wer ein Werkzeug schreiben will, das Prozesse oder Kernel-Zustände inspiziert, kommt nicht an /proc vorbei. Bibliotheken wie psutil (Python) abstrahieren das, lesen aber intern aus genau diesem Pfad. Für Bash-Skripte reicht oft direkter Zugriff per cat /proc/....

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Verzeichnisstruktur

Zur Übersicht