/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)