/ Artikel

/sys — Hardware und Kernel-Objekte

Vollständiger Überblick zu /sys unter Linux: Wie das sysfs-Pseudo-Dateisystem die Hardware als Dateien abbildet, welche Hierarchien (/sys/class, /sys/block, /sys/devices) sich wofür eignen, wie udev auf Events reagiert und wie sich Hardware-Eigenschaften (CPU-Frequenz, LEDs, Akku) lesen und teilweise schreiben lassen.

/sys ist ein vom Kernel bereitgestelltes Pseudo-Dateisystem (sysfs), das die gesamte erkannte Hardware sowie die geladenen Treiber und Kernel-Objekte als Dateien abbildet. Im Gegensatz zum historisch gewachsenen /proc ist sysfs strukturiert nach klaren Hierarchien — Geräte-Klassen, physische Bus-Topologie, Module, Filesysteme. Tools wie udev, hwinfo, lsblk lesen aus /sys; Power-Management, LED-Steuerung und CPU-Tuning passieren durch Schreiben dorthin.

01 · Abschnitt

Was ist sysfs?

sysfs wurde 2003 mit Kernel 2.6 eingeführt — als sauberer, strukturierter Ersatz für die wuchernden Hardware-Einträge unter /proc. Es belegt keinen Disk-Speicher, sondern wird vom Kernel beim Boot gemountet:

Bash sysfs als Mount

mount | grep sys
# sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)

# Top-Level-Hierarchien
ls /sys/
# block  bus  class  dev  devices  firmware  fs  kernel  module  power

Die Idee von sysfs ist einfach: jedes Kernel-Objekt (Gerät, Treiber, Bus, Klasse) wird als kobject verwaltet, und jedes kobject erscheint als Verzeichnis in sysfs. Eigenschaften des Objekts sind Dateien darin. Beziehungen zwischen Objekten werden durch Symlinks ausgedrückt — so spiegelt sich die Hardware-Topologie direkt im Filesystem.

02 · Abschnitt

Die wichtigsten Hierarchien

Unter /sys gibt es mehrere parallele Sichten auf dieselbe Hardware — jede aus einer anderen Perspektive:

Pfad	Sicht	Praktischer Einsatz
`/sys/devices/`	Physische Baumstruktur (Bus → Controller → Gerät)	Für tiefes Hardware-Debugging
`/sys/class/`	Geräte-Klassen (block, net, leds, power_supply, …)	Schneller Zugriff nach Gerätetyp
`/sys/block/`	Block-Devices (Disks, Partitionen)	I/O-Tuning, Disk-Statistiken
`/sys/bus/`	Pro Bus-Typ (pci, usb, scsi, …)	Treiber zu Geräten zuordnen
`/sys/module/`	Geladene Kernel-Module mit Parametern	Modul-Optionen prüfen und setzen
`/sys/fs/`	Filesystem-spezifische Parameter (cgroup, btrfs, ext4)	Mount-Optionen und Limits
`/sys/firmware/`	Firmware-Schnittstellen (ACPI, EFI, DMI)	Hardware-Inventar via DMI
`/sys/kernel/`	Kernel-interne Werte (security, mm, slab)	Selten direkt genutzt
`/sys/power/`	Power-Management-Schnittstelle	Suspend, Hibernate auslösen

/sys/class/ ist für die meisten Fälle der einfachste Einstieg. Die anderen Sichten (/sys/devices/, /sys/bus/) zeigen dasselbe Gerät aus einer anderen Perspektive — die Symlinks führen alle zur gleichen Stelle in /sys/devices/:

Bash Drei Wege zur selben Festplatte

# Über /sys/block — Block-Sicht
ls -la /sys/block/sda
# ../devices/pci0000:00/0000:00:17.0/ata1/host0/target0:0:0/0:0:0:0/block/sda

# Über /sys/class — Klassen-Sicht
ls -la /sys/class/block/sda
# ../../devices/pci0000:00/0000:00:17.0/.../block/sda

# Über /sys/bus — Bus-Sicht
ls -la /sys/bus/scsi/devices/0:0:0:0
# ../../../devices/pci0000:00/0000:00:17.0/ata1/host0/target0:0:0/0:0:0:0

03 · Abschnitt

Praxis: Hardware lesen

Was lässt sich aus sysfs auslesen? Praktisch alles, was die Hardware liefert. Ein paar typische Beispiele:

Bash Akku-Status auf Laptops

# Lade-Stand in Prozent
cat /sys/class/power_supply/BAT0/capacity

# Lade-Status (Charging, Discharging, Full, …)
cat /sys/class/power_supply/BAT0/status

# Lade-Zyklen (auf manchen Geräten)
cat /sys/class/power_supply/BAT0/cycle_count

# Aktuelle Stromzufuhr
ls /sys/class/power_supply/
# ADP1  BAT0  AC

# Komplett-Snapshot
for f in /sys/class/power_supply/BAT0/*; do
    [ -f "$f" ] && echo "$(basename $f): $(cat $f 2>/dev/null)"
done

Bash CPU-Frequenz und -Temperatur

# Aktuelle Frequenz pro Core
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
# 3593128

# Min/Max
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

# Verfügbare Governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
# performance powersave ondemand

# Governor setzen (root)
echo performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Temperatur (sensors zugängliche Quellen)
for f in /sys/class/thermal/thermal_zone*/temp; do
    echo "$f: $(($(cat $f) / 1000)) °C"
done

Bash Block-Device-Statistiken und Eigenschaften

# SSD oder HDD? rotational=0 bedeutet SSD
cat /sys/block/sda/queue/rotational
# 0

# Sektor-Größe
cat /sys/block/sda/queue/hw_sector_size

# I/O-Statistiken (Reads, Writes, Sektoren, ms)
cat /sys/block/sda/stat

# I/O-Scheduler
cat /sys/block/sda/queue/scheduler
# mq-deadline kyber [bfq] none      ← aktiver in []

# Scheduler ändern
echo none | sudo tee /sys/block/sda/queue/scheduler

Bash Netzwerk-Interfaces

# Alle Interfaces
ls /sys/class/net/

# MAC-Adresse
cat /sys/class/net/eth0/address

# Aktueller Link-Status
cat /sys/class/net/eth0/operstate
# up

# Geschwindigkeit (in Mbit/s)
cat /sys/class/net/eth0/speed
# 1000

# MTU
cat /sys/class/net/eth0/mtu

04 · Abschnitt

udev — der dynamische Verwalter

Sysfs alleine wäre nutzlos, wenn keiner zuhört. Hier kommt udev ins Spiel: ein User-Space-Daemon, der auf Kernel-Events lauscht. Wann immer der Kernel ein neues Gerät erkennt (USB-Stick eingesteckt, Wi-Fi-Adapter aktiviert, Disk angesteckt), schickt er ein uevent, und udev reagiert:

Erstellt einen Device-Node in /dev/ (z. B. /dev/sdb1 für eine neue Partition).
Setzt Berechtigungen und Eigentümer entsprechend Regeln in /etc/udev/rules.d/.
Triggert ggf. automatische Aktionen (Auto-Mount, Notification, Skript-Aufruf).

Bash udev in Action

# Live-Monitor: was passiert beim Einstecken eines USB-Sticks?
sudo udevadm monitor --kernel --property
# KERNEL[42.123] add /devices/.../block/sdb (block)
# KERNEL[42.140] add /devices/.../block/sdb/sdb1 (block)
# ACTION=add
# DEVNAME=/dev/sdb1
# ID_FS_TYPE=vfat
# ID_FS_LABEL=USB-STICK
# ...

# Alle Eigenschaften eines Geräts dump
sudo udevadm info --query=all --name=/dev/sda

# Wartet auf Test-Trigger einer Regel
sudo udevadm test /sys/class/net/eth0

Eigene udev-Regeln (z. B. „bestimmtes USB-Gerät bekommt persistenten Namen") gehören in /etc/udev/rules.d/<priority>-<name>.rules. Die Default-Regeln liefert die Distribution unter /lib/udev/rules.d/ (oder neuerdings /usr/lib/udev/rules.d/).

Bash Eigene udev-Regel: USB-Stick mit fester Symlink-Bezeichnung

# Identifikation eines konkreten USB-Sticks
sudo udevadm info --query=all --name=/dev/sdb1 \
    | grep -E 'ID_VENDOR_ID|ID_MODEL_ID|ID_SERIAL_SHORT'

# Regel anlegen
sudo $EDITOR /etc/udev/rules.d/99-mein-stick.rules

SUBSYSTEM=="block", ATTRS{idVendor}=="0951", ATTRS{idProduct}=="1666", \
    ATTRS{serial}=="...123456...", SYMLINK+="mein-stick", MODE="0660", GROUP="users"

# Regeln neu laden, ohne neu zu booten
sudo udevadm control --reload-rules
sudo udevadm trigger

Beim nächsten Einstecken erscheint dann zusätzlich /dev/mein-stick als Symlink — egal welche Sub-Buchstabe (sdb, sdc, …) der Kernel vergibt.

05 · Abschnitt

Hardware-Inventar via /sys/firmware/dmi

/sys/firmware/dmi/ macht die DMI/SMBIOS-Tabellen des BIOS/UEFI als Files lesbar — das ist die zuverlässigste Quelle für Maschinen-Modell, Hersteller, Seriennummer und BIOS-Version:

Bash System-Inventar aus DMI lesen

# Wichtigste Werte
cat /sys/devices/virtual/dmi/id/sys_vendor
# LENOVO

cat /sys/devices/virtual/dmi/id/product_name
# 21CD000DGE

cat /sys/devices/virtual/dmi/id/product_version
# ThinkPad X1 Carbon Gen 11

cat /sys/devices/virtual/dmi/id/bios_version
# N3HET90W (1.50)

# Kompletter Snapshot
for f in /sys/devices/virtual/dmi/id/{sys_vendor,product_name,product_version,bios_version,bios_date}; do
    echo "$(basename $f): $(cat $f 2>/dev/null)"
done

Tools wie dmidecode formatieren diese Tabellen als Text — die Quelle ist dieselbe.

06 · Abschnitt

Kernel-Module unter /sys/module

Jedes geladene Kernel-Modul taucht unter /sys/module/<name>/ auf, mit seinen Parametern und Referenzen:

Bash Modul-Parameter prüfen und ändern

# Geladene Module
ls /sys/module/ | head

# Parameter eines Moduls
ls /sys/module/snd_hda_intel/parameters/
# enable  index  model  power_save  power_save_controller

# Aktuellen Wert lesen
cat /sys/module/snd_hda_intel/parameters/power_save
# 1

# Setzen (root, sofern Modul es erlaubt)
echo 0 | sudo tee /sys/module/snd_hda_intel/parameters/power_save

# Persistent über /etc/modprobe.d/
echo 'options snd_hda_intel power_save=0' \
    | sudo tee /etc/modprobe.d/audio-no-powersave.conf

07 · Abschnitt

Interessantes

sysfs ist read-mostly — schreiben braucht Erfahrung

Die meisten Dateien in /sys sind nur informativ. Schreiben ist möglich, aber die Konsequenzen müssen klar sein. Ein falsch gesetzter scaling_governor, ein gestopptes Gerät via echo 0 > authorized — Hardware kann unbenutzbar werden, bis das System neu startet.

udev ersetzt nicht NetworkManager oder systemd

udev verwaltet Device-Nodes, nicht den Netzwerk-Stack oder Service-Lifecycles. Es legt /dev/eth0 an — aber die IP-Konfiguration übernimmt NetworkManager, systemd-networkd oder ifupdown. Wer beim Debugging die Schichten verwechselt, sucht an der falschen Stelle.

/sys-Pfade ändern sich zwischen Kernel-Versionen

Die Stabilitätsgarantien für sysfs sind enger als für ABIs, aber nicht absolut. Pfade in /sys/devices/ können sich beim Major-Kernel-Update verschieben — Skripte sollten sich daher auf /sys/class/<klasse>/<gerät>/ stützen, nicht auf physische Bus-Pfade.

Tools nutzen /sys, sind aber stabilere APIs

Statt cat /sys/class/power_supply/BAT0/capacity lieber upower -i $(upower -e | grep BAT) oder acpi -b — die Tools kennen Edge-Cases (ungültige Zustände, mehrere Akkus, fehlende Werte) besser als ein blindes cat. Direkter Zugriff ist trotzdem nützlich für eigene Skripte und Monitoring.

In Containern ist /sys oft read-only oder leer

Container sehen ein extrem ausgedünntes /sys — meist read-only und mit wenigen Subhierarchien (cgroup, devices). Hardware-Steuerung im Container ist standardmäßig blockiert (Sicherheits-Default). Wer Hardware-Zugriff braucht, muss mit --privileged oder gezielten --device-Mounts arbeiten — was die Isolation aufweicht.

DMI-Werte sind die zuverlässigste Maschinen-ID

cat /sys/devices/virtual/dmi/id/product_serial (root erforderlich) liefert die Seriennummer aus der Firmware. Stabiler als MAC-Adressen oder Disk-UUIDs — bleibt erhalten beim Disk-Tausch, beim OS-Wechsel, beim Mainboard-Reset. Praktisch für Inventar-Skripte.

08 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Verzeichnisstruktur

Zur Übersicht