/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