/run — Laufzeitdaten

Was ist /run?

/run ist seit FHS 3.0 (2015) der offizielle Pfad für Runtime-State — kurzlebige Daten, die nur Sinn ergeben, solange das System läuft. Drei Eigenschaften definieren das Verzeichnis:

1. tmpfs im RAM, also flüchtig und schnell.
2. Beim Boot sehr früh verfügbar — noch bevor /var gemountet sein muss.
3. Pro System eindeutig: /run selbst ist global, /run/user/<uid>/ pro User.

mount | grep ' /run '
# tmpfs on /run type tmpfs (rw,nosuid,nodev,size=...,mode=755)

# Größe und Belegung
df -h /run
# tmpfs   787M  4.2M  783M   1% /run

# Inhalt auf einen Blick
ls /run/
# NetworkManager   dbus           lock         systemd
# blkid            log            mount        udev
# cron.reboot      lvm            sshd.pid     user

Was du in /run findest:

Geschichte: von /var/run nach /run

Bis ca. 2012 lagen diese Daten unter /var/run (System) und /var/lock (Locks). Das hatte zwei Probleme:

1. /var wird erst spät im Boot-Prozess gemountet — Init-Scripts, die schon vorher PID-Files schreiben mussten, hatten ein Henne-Ei-Problem.
2. /var/run wurde selten als tmpfs gemountet — es konnte beim Crash unaufgeräumte Reste enthalten, die einen Service-Neustart blockierten.

Der Übergang zu systemd (Fedora 15 als erste Distro 2011, Debian 8 als „Jessie" 2015) brachte /run als eigenständiges tmpfs, das vor /var aktiv ist. Aus Kompatibilitäts-Gründen sind die alten Pfade jetzt Symlinks:

ls -la /var/run /var/lock
# lrwxrwxrwx 1 root root  4 ... /var/lock -> /run/lock
# lrwxrwxrwx 1 root root  4 ... /var/run  -> /run

# Effekt: dieselben Dateien, zwei Pfade
echo "test" > /tmp/test
ls -la /run/sshd.pid /var/run/sshd.pid
# -rw-r--r-- 1 root root 6 ... /run/sshd.pid
# -rw-r--r-- 1 root root 6 ... /var/run/sshd.pid   ← gleiche Datei

Programme können also /var/run/sshd.pid weiter ansprechen — der Symlink leitet transparent um. Neue Software sollte aber direkt /run/<name>.pid verwenden.

Pro-User: $XDG_RUNTIME_DIR und /run/user/

Eine wichtige Innovation seit systemd: pro Login-User wird ein eigenes Runtime-Verzeichnis angelegt — /run/user/<UID>/. Es gehört dem User mit Mode 0700, sodass nur er hineinschauen darf, und wird bei seinem Logout automatisch entfernt.

Die Standard-Variable $XDG_RUNTIME_DIR zeigt darauf:

echo "$XDG_RUNTIME_DIR"
# /run/user/1000

ls -la "$XDG_RUNTIME_DIR"
# drwx------ 13 michael michael  340 ... .
# ...
# drwxr-xr-x  2 michael michael   80 ... pulse
# srw-rw---- 1 michael michael    0 ... bus           ← dbus-Socket
# srw-rw---- 1 michael michael    0 ... pulse/native  ← PulseAudio
# drwxr-xr-x  3 michael michael   60 ... systemd
# ...

# Gehört uns alleine
stat -c '%a %U:%G' "$XDG_RUNTIME_DIR"
# 700 michael:michael

Was hier alles landet:

• dbus-Session-Socket für User-Apps
• PulseAudio-Socket
• GnuPG-Agent-Socket
• systemd --user-Sockets und PID-Files
• Wayland-Display-Socket (wayland-0, wayland-0.lock)

Das ist die richtige Stelle für kurzlebige User-Daten, die nicht persistent sein müssen. Skripte, die einen User-Socket anlegen wollen, gehören dorthin — nicht nach /tmp (wo andere User reinschauen können) und nicht nach ~/.local/state/ (wo der Reboot nichts bringt).

/run/lock und Sticky-Bit

/run/lock (vorher /var/lock) hat das Sticky-Bit gesetzt (Mode 1777), damit User Lock-Files anlegen können, ohne dass andere sie löschen:

ls -ld /run/lock
# drwxrwxrwt 4 root root  80 ... /run/lock

# Klassisches Beispiel: serielle Ports
ls /run/lock/
# subsys/        ← Service-Locks (z. B. cron, exim4)
# LCK..ttyUSB0   ← Lock für seriellen Port

Heute werden Lock-Files seltener manuell genutzt — moderne Programme bevorzugen flock() auf der Original-Datei (atomarer, aufräum-freundlicher). Das /run/lock-Pattern bleibt aber für Legacy-Software und einige Daemons aktiv.

Praxis: Sockets und PID-Files inspizieren

/run ist die erste Anlaufstelle, um zu prüfen, ob ein Service läuft und wie man mit ihm spricht:

# PID eines Daemons aus dem File lesen
cat /run/sshd.pid
# 1234

# Prüfen, ob der Prozess wirklich läuft
kill -0 $(cat /run/sshd.pid) && echo "läuft" || echo "tot"

# Was steckt sonst noch in /run?
find /run -maxdepth 2 -name '*.pid' 2>/dev/null

# Alle Unix-Sockets im /run-Baum
find /run -type s 2>/dev/null
# /run/docker.sock
# /run/dbus/system_bus_socket
# /run/systemd/notify
# /run/user/1000/pulse/native
# ...

# Wer hört auf welchem Socket?
sudo lsof -U /run/docker.sock
# COMMAND   PID  USER  FD  TYPE  ...  NAME
# dockerd  1023  root  3u  unix  ...  /run/docker.sock

# Aktive Units, die nicht persistent installiert sind
ls /run/systemd/system/
# session-c1.scope.d/  user-1000.slice.d/  ...

# systemd-private Tmp-Verzeichnis pro Service (PrivateTmp=yes)
sudo ls /run/systemd/private-* 2>/dev/null

Eigene Services: in /run schreiben

Wer einen eigenen Service schreibt, sollte PID-File und Socket nach /run/<servicename>/ legen — nicht in /tmp und nicht in /var. systemd hilft dabei mit der RuntimeDirectory=-Direktive:

# /etc/systemd/system/myapp.service
[Unit]
Description=Mein Service
After=network.target

[Service]
Type=simple
User=myapp
Group=myapp
ExecStart=/usr/local/bin/myapp --socket /run/myapp/sock --pid /run/myapp/pid

# systemd legt /run/myapp/ automatisch beim Start an,
# gehört User "myapp", Mode 0750 — und entfernt es beim Stop.
RuntimeDirectory=myapp
RuntimeDirectoryMode=0750

[Install]
WantedBy=multi-user.target

Vorteile dieser Direktive:

• Automatisches Anlegen: /run/myapp/ existiert beim Start, ohne dass das Programm es selbst tun muss.
• Saubere Berechtigungen: gehört dem konfigurierten User, nicht root.
• Automatisches Entfernen: beim Service-Stop wird das Verzeichnis entfernt — kein zurückbleibender Müll.

Weiterführende Ressourcen

Externe Quellen

• Filesystem Hierarchy Standard 3.0 — /run
• systemd: RuntimeDirectory= in systemd.exec(5)
• XDG Base Directory Specification — XDG_RUNTIME_DIR
• Linux man-pages: pid_namespaces(7)
• Linux man-pages: hier(7)

Verwandte Artikel

• Verzeichnisstruktur — Übersicht
• /tmp — Temporäre Dateien
• /var — Variable Daten
• /proc — Prozess- und Kernel-Informationen
• systemd-Grundlagen
• Berechtigungen unter Linux — Sticky-Bit, SUID