Hardware-Uhr und hwclock: System Clock und RTC unter Linux synchronisieren

1. System Clock und Hardware-Uhr: zwei getrennte Zeitgeber

Ein Linux-System besitzt praktisch immer zwei unabhaengige Uhren. Die System Clock ist ein Softwarezaehler im Kernel, der beim Systemstart initialisiert wird und danach vom Timer-Interrupt der CPU weiterlaeuft. Die Hardware-Uhr, auch RTC oder Real Time Clock genannt, ist ein eigener Chip auf dem Mainboard mit eigener Batterie, der auch bei ausgeschaltetem Rechner Sekunde fuer Sekunde weiterzaehlt. Das Kommando hwclock ist die klassische Schnittstelle zwischen beiden Welten und beim Boot dafuer verantwortlich, die System Clock aus der Hardware-Uhr zu uebernehmen.

Der praktische Unterschied wird sichtbar, sobald ein Rechner laenger als geplant ausgeschaltet bleibt oder die Batterie der Hardware-Uhr leer ist. Waehrend die System Clock beim naechsten Boot mit einem beliebigen, oft falschen Wert startet, liefert die RTC in der Regel einen brauchbaren Ausgangspunkt, solange die Batterie funktioniert. Fuer Server, die Zertifikate pruefen, Logs korrelieren oder Datenbank-Transaktionen zeitstempeln, ist eine korrekt gesetzte Hardware-Uhr deshalb kein Detail, sondern eine Grundvoraussetzung fuer den fehlerfreien Betrieb direkt nach dem Systemstart, bevor eine Zeitsynchronisation ueber das Netzwerk ueberhaupt greifen kann.

2. Die RTC im Detail: Batterie, Chip und Aufloesung

Physisch besteht die RTC aus einem kleinen, extrem stromsparenden Chip, meist auf Basis eines Quarzoszillators, der von einer Knopfzellenbatterie oder einem Kondensator versorgt wird. Diese Batterie haelt je nach Modell mehrere Jahre und ist der Grund dafuer, dass ein Laptop nach langem Lagern im Schrank trotzdem noch eine halbwegs richtige Uhrzeit anzeigt. Unter Linux erscheint die RTC als Geraetedatei unter /dev/rtc0 und stellt zusaetzliche Informationen unter /sys/class/rtc/rtc0/ bereit, etwa den aktuellen Wert, unterstuetzte Wakeup-Funktionen und den Namen des zugrunde liegenden Treibers.

Ein wichtiger Unterschied zur System Clock: Die Hardware-Uhr speichert in vielen Implementierungen nur Sekunden, keine Sub-Sekunden-Aufloesung. Das ist fuer den reinen Boot-Zeitstempel unproblematisch, macht die RTC aber ungeeignet als alleinige Zeitquelle fuer Anwendungen mit Millisekunden-Anforderungen. Zusaetzlich driftet praktisch jeder Quarzoszillator mit der Zeit, meist im Bereich weniger Sekunden pro Monat, abhaengig von Temperatur und Bauteilqualitaet. Dieser Drift ist der eigentliche Grund, warum die Kombination aus RTC und Netzwerkzeit sinnvoller ist als sich ausschliesslich auf die Hardware-Uhr zu verlassen.

# Inspect the RTC device and its capabilities
ls /sys/class/rtc/
cat /sys/class/rtc/rtc0/name
cat /sys/class/rtc/rtc0/since_epoch

# Read the raw RTC time directly from the kernel driver
sudo hwclock --show --verbose

3. hwclock in der Praxis: show, systohc, hctosys

Das Werkzeug hwclock kennt im Kern drei Operationen. hwclock --show liest die Hardware-Uhr aus und zeigt sie an, ohne etwas zu veraendern, ideal fuer eine schnelle Diagnose. hwclock --systohc schreibt die aktuelle System Clock in die Hardware-Uhr und wird typischerweise nach einer erfolgreichen Netzwerksynchronisation aufgerufen, damit die RTC beim naechsten Kaltstart einen aktuellen Wert liefert. hwclock --hctosys geht den umgekehrten Weg und setzt die System Clock aus der Hardware-Uhr, ein Schritt, den systemd beim Boot ohnehin automatisch ausfuehrt, bevor Netzwerkdienste ueberhaupt gestartet sind.

In der Praxis ruft man hwclock manuell selten auf, weil moderne Distributionen den Ablauf ueber systemd-Dienste automatisieren. Trotzdem ist der manuelle Aufruf bei Diagnosen unverzichtbar, etwa um zu pruefen, ob eine Abweichung zwischen System Clock und Hardware-Uhr vorliegt, oder um nach einem BIOS-Update oder Batteriewechsel die Hardware-Uhr gezielt neu zu setzen. Wichtig ist, hwclock nie parallel zu einem laufenden NTP-Dienst wie chrony aufzurufen, ohne diesen kurz zu pausieren, da sonst zwei Prozesse gleichzeitig versuchen, dieselbe Uhr zu korrigieren.

# Show the current hardware clock value without changing anything
sudo hwclock --show

# Write the (already synced) system clock into the hardware clock
sudo hwclock --systohc

# Set the system clock from the hardware clock (normally done at boot)
sudo hwclock --hctosys

# Manually set a specific hardware clock value (rare, for recovery only)
sudo hwclock --set --date="2026-07-30 14:32:00"

4. UTC vs. lokale Zeit in der Hardware-Uhr

Eine der haeufigsten Ursachen fuer Verwirrung ist die Frage, ob die Hardware-Uhr UTC oder lokale Zeit speichert. Linux-Distributionen setzen standardmaessig UTC in der RTC voraus, was aus mehreren Gruenden die richtige Wahl ist: Zeitzonenwechsel und Sommerzeit-Umstellungen betreffen dann nur die Interpretation der Zeit in der System Clock, nicht die gespeicherten Rohwerte in der Hardware-Uhr selbst. Windows dagegen speichert historisch die lokale Zeit in der RTC, was auf Dual-Boot-Systemen zu einer Verschiebung von mehreren Stunden fuehrt, sobald man zwischen beiden Betriebssystemen wechselt.

Der Befehl timedatectl set-local-rtc 1 stellt Linux auf lokale RTC-Zeit um, was auf reinen Dual-Boot-Desktops eine praktikable Loesung sein kann, auf Servern aber unbedingt vermieden werden sollte. Server sollten konsequent bei timedatectl set-local-rtc 0, also UTC in der Hardware-Uhr, bleiben, weil das die einzige Einstellung ist, die mit automatisierten Deployments, Container-Hosts und virtuellen Maschinen ohne zusaetzliche Fallstricke funktioniert. Die Einstellung selbst landet in der Datei /etc/adjtime, die neben dem RTC-Modus auch die zuletzt gemessene Drift-Rate speichert.

# /etc/adjtime — persisted state used by hwclock
# Line 1: measured drift factor (seconds per day) and last calibration timestamp
# Line 2: last time hwclock was called
# Line 3: RTC mode, either UTC or LOCAL

0.123456 1785500000 0.500000
1785500000
UTC

5. Zusammenspiel mit systemd und timedatectl beim Boot

Auf systemd-Systemen uebernimmt systemd-timesyncd oder alternativ chrony beim Boot einen Grossteil der klassischen hwclock-Aufgaben implizit. Direkt nach dem Kernel-Start liest systemd die Hardware-Uhr aus, setzt daraus die System Clock und startet danach die Netzwerkzeit-Synchronisation. Sobald diese erfolgreich war, kann systemd konfiguriert werden, die neue, praezise Zeit periodisch wieder in die Hardware-Uhr zurueckzuschreiben, damit ein spaeterer Kaltstart von einem moeglichst genauen Ausgangswert profitiert, selbst wenn das Netzwerk beim naechsten Boot kurzzeitig nicht erreichbar ist.

Der Befehl timedatectl ist die moderne, systemd-native Sicht auf beide Uhren gleichzeitig und zeigt in seiner Ausgabe sowohl die lokale Zeit als auch den RTC-Status und ob die Zeit ueber NTP synchronisiert ist. Wer alte Init-Skripte oder Cron-basierte hwclock-Aufrufe aus vor-systemd-Zeiten in ein aktuelles System uebernimmt, riskiert Race Conditions mit den systemd-eigenen Mechanismen. Auf modernen Distributionen reicht es fast immer, timedatectl set-ntp true zu setzen und chronyd die Feinsynchronisation sowie die periodische Aktualisierung der Hardware-Uhr zu ueberlassen.

6. Clock Drift messen und mit adjtime korrigieren

Jeder Quarzoszillator hat eine individuelle, meist temperaturabhaengige Abweichung von der Sollfrequenz, die als Drift bezeichnet wird. Der Kernel misst diese Drift automatisch, sobald die Hardware-Uhr regelmaessig mit einer genauen externen Quelle abgeglichen wird, und speichert die ermittelte Rate in Sekunden pro Tag in /etc/adjtime. Diese gespeicherte Rate nutzt hwclock danach, um die RTC zwischen zwei Synchronisationen automatisch vorzukorrigieren, sodass die Abweichung im Alltag praktisch nicht mehr auffaellt.

In der Praxis lohnt sich ein Blick auf den Drift-Wert vor allem bei aelterer Server-Hardware oder virtuellen Maschinen mit emulierter RTC, bei denen ungewoehnlich hohe Drift-Werte auf ein zugrunde liegendes Problem im Hypervisor hindeuten koennen. Ein Drift von mehr als wenigen Sekunden pro Tag ist ein Warnsignal und rechtfertigt einen genaueren Blick auf die Virtualisierungsschicht, da eine funktionierende Netzwerkzeit-Synchronisation die zugrunde liegende Drift zwar kaschiert, aber nicht das eigentliche Problem am Hypervisor loest.

7. Die RTC in virtuellen Maschinen und Cloud-Instanzen

Virtuelle Maschinen besitzen keine echte, batteriegepufferte Hardware-Uhr, sondern eine vom Hypervisor emulierte RTC. KVM, VMware und die meisten Cloud-Plattformen bilden das Verhalten einer physischen Uhr nach, koppeln die Genauigkeit aber zusaetzlich an die Taktgebung des Host-Systems. Das fuehrt zu einem bekannten Phaenomen: Unter hoher Host-Last oder nach dem Zurueckspielen eines Snapshots kann die emulierte Uhrzeit der Gast-VM merklich von der realen Zeit abweichen, teils um mehrere Minuten, bis eine Netzwerksynchronisation den Fehler behebt.

Fuer Cloud-Instanzen empfiehlt sich deshalb, chronyd mit kurzen Poll-Intervallen zu betreiben und, wo verfuegbar, die vom Cloud-Anbieter bereitgestellte interne Zeitquelle zu nutzen, statt sich ausschliesslich auf oeffentliche NTP-Pools zu verlassen. Nach dem Wiederherstellen eines Snapshots oder nach einer Live-Migration ist ein sofortiger, erzwungener Zeitabgleich sinnvoll, etwa mit chronyc makestep, damit Anwendungen nicht mit einer veralteten Uhrzeit starten, waehrend die reguläre, schrittweise Korrektur noch laeuft.

# Force an immediate time step instead of gradual slewing (use after snapshot restore)
sudo chronyc makestep

# Check current offset and whether the system is considered synchronized
chronyc tracking

# On cloud VMs: verify which RTC device is actually exposed to the guest
dmesg | grep -i rtc

8. Typische Symptome einer falschen Hardware-Uhr

Eine falsch eingestellte oder driftende Hardware-Uhr zeigt sich selten direkt, sondern ueber Symptome an anderer Stelle. TLS-Verbindungen schlagen mit Zertifikatsfehlern fehl, weil das Gueltigkeitsfenster eines Zertifikats knapp verpasst wird. Log-Eintraege verschiedener Systeme lassen sich nicht mehr korrekt korrelieren, weil Zeitstempel systematisch verschoben sind. Geplante Backups laufen zur falschen Uhrzeit oder ueberlappen sich, weil Cronjobs auf Basis einer falschen Systemzeit ausgeloest werden, bevor die Netzwerkzeit-Synchronisation ueberhaupt greifen konnte.

Der erste Diagnoseschritt bei solchen Symptomen ist immer derselbe: hwclock --show mit date vergleichen und pruefen, ob beide Werte deutlich auseinanderliegen. Liegt die Abweichung im Minuten- oder Stundenbereich, deutet das auf eine leere RTC-Batterie, einen falschen UTC/Localtime-Modus oder einen fehlgeschlagenen Boot-Abgleich hin. Liegt die Abweichung im Sekundenbereich und wiederholt sich regelmaessig, handelt es sich meist um normale Drift, die durch eine funktionierende Netzwerkzeit-Synchronisation ohnehin fortlaufend korrigiert wird und keinen manuellen Eingriff erfordert.

9. hwclock, timedatectl und chronyc im Vergleich

Alle drei Werkzeuge betreffen Zeit unter Linux, decken aber unterschiedliche Ebenen ab und schliessen sich nicht gegenseitig aus. Wer weiss, welches Werkzeug fuer welche Aufgabe zustaendig ist, spart sich in der Praxis viele Fehldiagnosen und unnoetige manuelle Eingriffe in Systeme, die eigentlich automatisch korrekt funktionieren.

In der Regel greifen die Werkzeuge automatisch ineinander: chronyd haelt die System Clock praezise, systemd sorgt beim Boot fuer den initialen Abgleich mit der Hardware-Uhr, und hwclock bleibt als manuelles Diagnose- und Recovery-Werkzeug im Hintergrund. Nur bei Sonderfaellen wie Dual-Boot-Systemen, alten Init-Systemen oder Hardware ohne funktionierende RTC-Batterie muss man tatsaechlich manuell eingreifen und die Zusammenhaenge zwischen den drei Ebenen im Detail verstehen.

10. Zusammenfassung

Die Hardware-Uhr und die System Clock sind zwei getrennte Zeitgeber, die durch hwclock beim Boot und danach durch systemd miteinander verbunden werden. Die RTC laeuft batteriegepuffert weiter, wenn der Rechner aus ist, driftet aber mit der Zeit und liefert nur Sekundenaufloesung. UTC ist der richtige Modus fuer die Hardware-Uhr auf Servern, lokale Zeit gehoert dort nicht hin und sollte hoechstens auf Dual-Boot-Desktops verwendet werden. Die Drift-Rate wird automatisch in /etc/adjtime gespeichert und von hwclock zur Vorkorrektur genutzt.

In virtuellen Maschinen ist die RTC emuliert und kann nach Snapshots oder Migrationen kurzzeitig deutlich abweichen, weshalb ein erzwungener Zeitschritt mit chronyc makestep sinnvoll ist. Symptome einer falschen Hardware-Uhr zeigen sich meist indirekt, ueber Zertifikatsfehler, verschobene Logs oder falsch getriggerte Cronjobs, nicht ueber eine offensichtliche Fehlermeldung. Wer hwclock, timedatectl und chronyc als sich ergaenzende Werkzeuge auf unterschiedlichen Ebenen versteht, diagnostiziert Zeitprobleme deutlich schneller.

11. FAQ: Hardware-Uhr und hwclock unter Linux