dmesg Kernel-Log-Analyse: Fehler im Ringpuffer systematisch finden

1. Was der Kernel-Ringpuffer ist und wie dmesg ihn liest

Der Befehl dmesg liest den Kernel-Ringpuffer, eine im Kernel-Speicher fest reservierte, begrenzt grosse Datenstruktur, in die der Kernel seit dem Booten jede wichtige Meldung schreibt. Der Name dmesg steht fuer display message, und weil es ein Ringpuffer ist, ueberschreiben neue Meldungen die aeltesten, sobald der reservierte Speicher voll ist. Genau das ist der zentrale praktische Punkt jeder Kernel-Log-Analyse: Auf einem System mit sehr aktivem Kernel-Logging, etwa durch haeufige Hardware-Events, koennen wichtige aeltere Meldungen bereits ueberschrieben sein, bevor ein Administrator sie liest.

Ohne Argumente zeigt dmesg den kompletten aktuellen Inhalt des Puffers seit dem letzten Boot. Die Groesse des Puffers wird beim Kernel-Start ueber den Boot-Parameter log_buf_len festgelegt und liegt auf modernen Systemen meist zwischen 256 KB und mehreren Megabyte, deutlich mehr als frueher, aber immer noch endlich. Fuer eine effektive Kernel-Log-Analyse reicht rohes dmesg selten aus, weil der Puffer schnell unuebersichtlich wird. Die Kombination aus Zeitfilterung, Log-Level-Filterung und gezieltem Grep macht aus dem Rohdatenstrom eine brauchbare Diagnosequelle.

# Show the entire current ring buffer content since last boot
dmesg

# Show buffer size configured at boot (kernel parameter log_buf_len)
cat /proc/cmdline | grep -o 'log_buf_len=[^ ]*'

# Human-readable timestamps instead of raw boot-relative seconds
dmesg -T

# Colorize output by severity, easier to scan visually
dmesg -x --color=always | less -R

2. Zeitstempel und Reihenfolge richtig interpretieren

Standardmaessig zeigt dmesg Zeitstempel als Sekunden seit dem Systemstart, in eckigen Klammern, etwa [ 3.482911]. Diese boot-relative Zeit ist fuer die Kernel-Log-Analyse direkt nach einem Neustart nuetzlich, wird aber bei einem System mit hoher Uptime schnell unhandlich, weil man selbst umrechnen muesste, welchem Kalenderdatum [ 892341.223] entspricht. Die Option -T wandelt diese Zeitstempel in menschenlesbare Kalenderzeit um, basierend auf der aktuellen Systemzeit und der Differenz zur Boot-Zeit.

Wichtige Einschraenkung, die viele bei der Kernel-Log-Analyse uebersehen: Die -T-Umrechnung ist eine Naeherung, weil sie keine NTP-Zeitkorrekturen zwischen Boot und aktuellem Zeitpunkt beruecksichtigt. Bei Systemen, deren Uhr beim Boot stark abwich und erst spaeter per NTP synchronisiert wurde, koennen die umgerechneten Zeitstempel um mehrere Minuten von der tatsaechlichen Ereigniszeit abweichen. Fuer forensische Genauigkeit, etwa bei einer Sicherheitsuntersuchung, ist journalctl -k vorzuziehen, weil systemd-journald jeden Eintrag mit einem eigenen, korrekt synchronisierten Zeitstempel versieht statt ihn nachtraeglich zu berechnen.

# Raw boot-relative timestamp in seconds
dmesg | head -3
# [    0.000000] Linux version 6.8.0-generic ...
# [    0.004123] Command line: BOOT_IMAGE=...

# Human-readable calendar time (approximate, not NTP-corrected)
dmesg -T | head -3
# [Thu Jul 30 08:12:03 2026] Linux version 6.8.0-generic ...

# For forensic accuracy, prefer journalctl, which stores real timestamps
journalctl -k --since "1 hour ago" -o short-precise

# Find how long the system has been up (context for interpreting timestamps)
uptime -s

3. Log-Level filtern: von Notfall bis Debug

Jede Kernel-Meldung traegt einen Schweregrad, dieselbe Skala wie bei syslog: 0 fuer emerg (System unbrauchbar), 1 fuer alert, 2 fuer crit, 3 fuer err, 4 fuer warn, 5 fuer notice, 6 fuer info und 7 fuer debug. In der Standardausgabe von dmesg ist dieser Level nicht direkt sichtbar, aber mit der Option -l laesst sich gezielt nach Schweregrad filtern, was fuer eine fokussierte Kernel-Log-Analyse unverzichtbar ist. Auf einem produktiven System mit tausenden Zeilen im Puffer ist dmesg -l err,crit,alert,emerg oft der schnellste Weg, direkt zu den relevanten Problemen zu springen, ohne informative, aber irrelevante Meldungen durchsuchen zu muessen.

Die Option -x zeigt zusaetzlich zum Log-Level auch die Facility, also die Kernel-Subsystem-Kategorie einer Meldung, was bei der Unterscheidung zwischen echten Hardwarefehlern und harmlosen informativen Meldungen hilft. Ein haeufiger Anfaengerfehler bei der Kernel-Log-Analyse: Meldungen mit Level warn werden pauschal ignoriert, obwohl manche Warnungen, etwa wiederholte ECC-Speicherkorrekturen, fruehe Anzeichen fuer bald ausfallende Hardware sind. Eine gute Praxis ist, warn und hoehere Level regelmaessig zu ueberpruefen, statt sich ausschliesslich auf err und schlimmer zu beschraenken.

# Filter by severity level, skipping informational noise
dmesg -l err,crit,alert,emerg

# Show facility (subsystem) alongside severity
dmesg -x | tail -30

# Common facilities: kern, daemon, user; common levels: err, warn, info
dmesg -l warn,err,crit -x

# Count messages by severity to spot an unusually noisy subsystem
dmesg -x | awk -F: '{print $1}' | sort | uniq -c | sort -rn

4. Hardware- und Treiberfehler in dmesg erkennen

Der klassische Anwendungsfall fuer dmesg ist die Diagnose von Hardwareproblemen, weil der Kernel jeden erkannten Fehler eines Geraetetreibers unmittelbar protokolliert. Ein defekter oder ueberhitzter Datentraeger zeigt sich typischerweise durch wiederholte I/O error- oder ATA error-Meldungen mit der betroffenen Geraetebezeichnung wie sda oder nvme0n1. Netzwerkkartenprobleme aeussern sich oft als link down gefolgt von link up in schneller Folge, ein Muster, das auf ein instabiles Kabel oder einen defekten Switch-Port hindeutet, statt auf ein Softwareproblem.

Fuer die Kernel-Log-Analyse bei Hardwareverdacht ist die Kombination aus grep auf das betroffene Geraet und die Betrachtung des zeitlichen Kontexts entscheidend: Ein einzelner I/O-Fehler kann ein voruebergehendes Ereignis sein, eine Serie mit steigender Frequenz ueber Stunden oder Tage deutet auf fortschreitenden Hardwareverschleiss hin. SMART-Daten mit smartctl ergaenzen dmesg dabei, indem sie proaktive Selbsttest-Ergebnisse liefern, waehrend dmesg reaktiv zeigt, was der Kernel bereits als Fehler registriert hat.

# Disk I/O errors, filtered by device name
dmesg -T | grep -iE "sda|nvme0n1" | grep -iE "error|fail"

# Network link flapping pattern (unstable cable or switch port)
dmesg -T | grep -iE "link (is )?(up|down)"

# USB device connect/disconnect events, useful for intermittent hardware
dmesg -T | grep -i usb | tail -20

# Generic hardware error scan across the whole buffer
dmesg -T -l err,crit,alert,emerg | grep -iE "error|fault|fail|timeout"

# Cross-check with SMART for proactive disk health, complementary to dmesg
sudo smartctl -a /dev/sda | grep -i "reallocated\|pending"

5. OOM-Killer-Meldungen lesen und verstehen

Wenn dem System der verfuegbare Speicher ausgeht, greift der Out-Of-Memory-Killer des Kernels ein und beendet gezielt einen Prozess, um das System vor einem kompletten Absturz zu bewahren. Diese Entscheidung wird ausfuehrlich im Kernel-Ringpuffer protokolliert, und die Kernel-Log-Analyse dieser Meldungen ist oft der einzige Weg herauszufinden, warum ein Prozess ohne erkennbaren eigenen Fehler ploetzlich verschwunden ist. Die Meldung Out of memory: Killed process 1234 (php-fpm) nennt sowohl PID als auch Prozessname des beendeten Prozesses.

Vor dieser finalen Zeile protokolliert der Kernel eine ausfuehrliche Tabelle aller Prozesse mit ihrem oom_score, dem internen Wert, nach dem der OOM-Killer entscheidet, welcher Prozess geopfert wird. Ein hoher oom_score bedeutet ein hoeheres Risiko, ausgewaehlt zu werden, beeinflusst durch Speicherverbrauch und den justierbaren Wert oom_score_adj. Diese Tabelle in dmesg zeigt exakt, welche Prozesse zum Zeitpunkt des Ereignisses wie viel Speicher belegten, und ist damit oft aussagekraeftiger als nachtraegliches Monitoring, das den Zustand vor dem Absturz nicht mehr rekonstruieren kann.

# Find every OOM-killer event in the current buffer
dmesg -T | grep -i "out of memory"

# The line that names the actual killed process
dmesg -T | grep -i "killed process"
# [Thu Jul 30 03:14:02 2026] Out of memory: Killed process 1234 (php-fpm)
#   total-vm:892340kB, anon-rss:412332kB, file-rss:0kB

# Full context: the process table dmesg prints right before the kill
dmesg -T | grep -B 40 "Killed process" | grep -E "oom_score_adj|pid|php-fpm"

# Persistent OOM history across reboots via journalctl
journalctl -k --since "7 days ago" | grep -i "out of memory"

6. Netzwerk- und Dateisystem-Warnungen im Ringpuffer

Dateisystemfehler gehoeren zu den kritischsten Meldungen, die eine Kernel-Log-Analyse aufdecken kann, weil sie oft auf Datenkorruption hindeuten. Meldungen wie EXT4-fs error oder XFS: Internal error zeigen an, dass der Kernel eine Inkonsistenz in der Dateisystemstruktur entdeckt hat, meist verursacht durch einen unsauberen Shutdown, einen Hardwarefehler auf dem darunterliegenden Datentraeger, oder in seltenen Faellen einen Kernel-Bug. Solche Meldungen sollten nie ignoriert werden, weil manche Dateisysteme sich nach einem solchen Fehler automatisch in einen Nur-Lese-Modus versetzen, um weiteren Schaden zu verhindern.

Auf der Netzwerkseite protokolliert der Kernel unter anderem TCP-Retransmission-Probleme, ARP-Konflikte bei doppelten IP-Adressen im lokalen Netz, und Firewall-Drops, sofern iptables oder nftables mit einem LOG-Target konfiguriert sind. Diese geloggten Firewall-Drops erscheinen ebenfalls im Kernel-Ringpuffer, weil sie vom Netfilter-Subsystem im Kernel selbst erzeugt werden, nicht von einem Userspace-Daemon. Fuer die Kernel-Log-Analyse im Netzwerkkontext ist deshalb dmesg eine vollwertige Ergaenzung zu klassischen Netzwerktools wie tcpdump, gerade fuer Ereignisse, die auf Kernel-Ebene entschieden werden.

# Filesystem corruption warnings (never ignore these)
dmesg -T | grep -iE "ext4-fs error|xfs.*internal error|i/o error"

# Duplicate IP address detected via ARP conflict
dmesg -T | grep -i "duplicate address"

# Firewall drops logged via iptables/nftables LOG target (kernel-level)
dmesg -T | grep -i "IN=.*OUT=.*"

# TCP-level retransmission or connection reset noise
dmesg -T | grep -iE "tcp.*retransmit|connection reset"

7. Persistentes Logging: dmesg-Grenzen und journalctl -k

Ein zentraler Nachteil von reinem dmesg: Es zeigt ausschliesslich den Puffer des aktuellen Boots, ausser das System nutzt ein persistentes Kernel-Log-Verzeichnis. Nach einem Neustart ist die gesamte Historie des vorherigen Boots verloren, was eine rueckwirkende Kernel-Log-Analyse nach einem Absturz unmoeglich macht, sofern nicht vorgesorgt wurde. Systemd-basierte Distributionen loesen das ueber journalctl -k, das dieselben Kernel-Meldungen liest, aber persistent auf der Festplatte speichert, sofern Storage=persistent in /etc/systemd/journald.conf gesetzt ist.

Der entscheidende Vorteil von journalctl -k gegenueber reinem dmesg: Boot-Historie bleibt erhalten und ist ueber journalctl -k -b -1 fuer den vorletzten Boot abrufbar, was besonders nach einem unerwarteten Neustart wertvoll ist, um die letzte Meldung vor dem Ausfall zu finden. Ohne persistentes Journal-Logging bleibt nur die Hoffnung, dass ein externer Log-Collector die dmesg-Ausgabe bereits vor dem Absturz weitergeleitet hat, was in vielen Standard-Setups nicht der Fall ist.

# Enable persistent journal storage (survives reboots)
sudo mkdir -p /etc/systemd/journald.conf.d
cat <<'EOF' | sudo tee /etc/systemd/journald.conf.d/persistent.conf
[Journal]
Storage=persistent
SystemMaxUse=500M
EOF
sudo systemctl restart systemd-journald

# Kernel messages from the current boot
journalctl -k -b 0

# Kernel messages from the previous boot (crash investigation)
journalctl -k -b -1

# List all available boots with their approximate time range
journalctl --list-boots

8. dmesg in Monitoring und Automatisierung einbinden

Fuer produktive Systeme lohnt es sich, die Kernel-Log-Analyse nicht nur reaktiv bei Problemen, sondern kontinuierlich zu automatisieren. Ein einfaches Cron-Skript, das regelmaessig nach kritischen Log-Levels sucht und bei neuen Treffern alarmiert, faengt viele Hardwareprobleme frueh ab, bevor sie zu einem Ausfall eskalieren. Wichtig dabei: Der Skript-Zustand muss gespeichert werden, etwa der letzte gesehene Zeitstempel, damit dieselbe Meldung nicht bei jedem Lauf erneut einen Alarm ausloest.

Fuer eine dauerhafte Integration in bestehende Monitoring-Stacks bietet sich journalctl -k -f als Follow-Modus an, der neue Kernel-Meldungen in Echtzeit ausgibt und sich in ein Log-Shipping-Tool wie Filebeat oder Fluentd einspeisen laesst. Die Kernel-Log-Analyse wird so Teil des zentralen Logging statt einer isolierten, manuellen Aufgabe, die nur nach einem bereits eingetretenen Vorfall durchgefuehrt wird.

#!/usr/bin/env bash
# Simple cron-driven check for new critical kernel messages
set -euo pipefail

STATE_FILE="/var/lib/dmesg-monitor/last-check.timestamp"
mkdir -p "$(dirname "$STATE_FILE")"

LAST_CHECK=$(cat "$STATE_FILE" 2>/dev/null || echo "1970-01-01 00:00:00")
NOW=$(date '+%Y-%m-%d %H:%M:%S')

NEW_CRITICAL=$(journalctl -k --since "$LAST_CHECK" -p err..emerg -o cat)

if [[ -n "$NEW_CRITICAL" ]]; then
  echo "[ALERT] New critical kernel messages since $LAST_CHECK:"
  echo "$NEW_CRITICAL"
  # Send to alerting system, e.g. curl to a webhook
fi

echo "$NOW" > "$STATE_FILE"

# Real-time follow mode, suitable for feeding a log shipper
# journalctl -k -f -o json | your-log-shipper --stdin

9. dmesg im Vergleich zu anderen Log-Quellen

dmesg ist eine von mehreren Log-Quellen unter Linux, und die richtige Kernel-Log-Analyse erfordert zu wissen, welche Quelle fuer welche Art von Meldung zustaendig ist.

In der Praxis ergaenzen sich diese Quellen: dmesg fuer die schnelle Live-Pruefung direkt auf dem Server, journalctl -k fuer die Analyse nach einem Ausfall inklusive vorherigem Boot, und Anwendungslogs fuer alles, was oberhalb der Kernel-Ebene passiert. Eine vollstaendige Kernel-Log-Analyse beruecksichtigt immer, welche Ebene ein Problem betrifft, statt sich auf eine einzige Log-Quelle zu verlassen.

10. Zusammenfassung

Die Kernel-Log-Analyse mit dmesg ist eine der direktesten Methoden, um zu verstehen, was auf Kernel-Ebene wirklich passiert, von Hardwareerkennung beim Boot bis zu OOM-Kills im laufenden Betrieb. Der Kernel-Ringpuffer, den dmesg auslesbar macht, ist begrenzt gross und verliert bei einem Neustart seinen Inhalt, weshalb persistentes Logging ueber journalctl -k fuer produktive Systeme unverzichtbar ist. Log-Level-Filterung mit dmesg -l und die Zeitstempel-Umrechnung mit -T machen aus dem rohen Puffer eine gezielt durchsuchbare Diagnosequelle.

Wer die Kernel-Log-Analyse in Monitoring-Skripte integriert, statt sie nur reaktiv nach einem Ausfall durchzufuehren, entdeckt Hardwareprobleme, Speicherengpaesse und Dateisystemwarnungen oft, bevor sie zum vollstaendigen Ausfall fuehren. Die Kombination aus dmesg fuer die schnelle Live-Pruefung und journalctl -k fuer die historische Analyse ueber Boots hinweg deckt den kompletten praktischen Bedarf ab.

11. FAQ: dmesg Kernel-Log-Analyse