/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:
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:
- Pro-Prozess-Verzeichnisse (
/proc/<PID>/) — pro laufendem Prozess ein Unterordner mit allen Informationen über diesen Prozess. - 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:
| Pfad | Inhalt |
|---|---|
/proc/<PID>/cmdline | Aufrufzeile (NUL-getrennte Argumente) |
/proc/<PID>/comm | Programm-Name (gekürzt auf 16 Zeichen) |
/proc/<PID>/status | Lesbarer Statusbericht (RSS, VmSize, UID, GID, …) |
/proc/<PID>/stat | Maschinen-lesbare Status-Werte (für ps, top) |
/proc/<PID>/fd/ | Symlinks auf alle geöffneten File-Descriptors |
/proc/<PID>/maps | Memory-Layout: welche Dateien wohin in RAM gemappt sind |
/proc/<PID>/environ | Umgebungsvariablen (NUL-getrennt) |
/proc/<PID>/exe | Symlink auf das ausgeführte Binary |
/proc/<PID>/cwd | Symlink aufs aktuelle Arbeitsverzeichnis |
/proc/<PID>/root | Symlink aufs Wurzel-Verzeichnis (relevant bei chroot) |
/proc/<PID>/limits | Resource-Limits (ulimit) |
/proc/<PID>/io | I/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) |
# $$ 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/$$/limitsPro-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:
| Datei | Inhalt |
|---|---|
/proc/cpuinfo | CPU-Modell, Cores, Cache, Flags pro Core |
/proc/meminfo | Speicher-Statistik (Total, Free, Available, Buffers, Cached) |
/proc/loadavg | 1/5/15-Minuten-Load-Averages und aktive/Total-Prozesse |
/proc/uptime | Uptime und idle time in Sekunden |
/proc/stat | CPU-Auslastung, Context-Switches, Forks (vmstat-Quelle) |
/proc/diskstats | I/O-Statistiken pro Device |
/proc/mounts | Aktuell eingehängte Filesysteme (für mount ohne Argumente) |
/proc/swaps | Aktive Swap-Bereiche |
/proc/modules | Geladene Kernel-Module (für lsmod) |
/proc/cmdline | Boot-Parameter, mit denen der Kernel gestartet wurde |
/proc/version | Kernel-Version, Compiler, Build-Datum |
/proc/interrupts | Interrupt-Statistik pro IRQ und CPU |
/proc/net/ | Netzwerk-Stack-Statistiken |
/proc/scsi/, /proc/iomem | Hardware-Mapping |
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:
# 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 einlesenHäufig genutzte Parameter:
| Parameter | Zweck |
|---|---|
net.ipv4.ip_forward | IP-Forwarding aktivieren (Router/NAT) |
net.ipv4.tcp_syncookies | SYN-Flood-Schutz aktivieren |
net.ipv4.tcp_fin_timeout | TIME_WAIT-Verhalten — relevant für Hochlast-Server |
net.core.somaxconn | Max. Backlog-Queue für Listen-Sockets |
vm.swappiness | Wie aggressiv der Kernel swappt (0–100) |
vm.overcommit_memory | Memory-Overcommit-Strategie |
fs.file-max | System-weites Limit für offene Dateien |
kernel.pid_max | Maximale PID — wichtig auf Containerhost mit vielen Prozessen |
kernel.dmesg_restrict | Beschrä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).
# 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# /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)'# /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/cpuinfozeigen die Host-CPU, nicht limits via cgroups. Tools wienprocmü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.
# 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.scopeInteressantes
/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
- Filesystem Hierarchy Standard 3.0 — /proc
- Linux Kernel: Documentation/filesystems/proc.rst
- man 5 proc — die ausführliche Manpage zu procfs
- man 7 sysctl
- Linux man-pages: hier(7)