Provided by: util-linux-locales_2.39.3-9ubuntu6.3_all 
BEZEICHNUNG
hwclock - Zeituhren-Hilfswerkzeug
ÜBERSICHT
hwclock [Funktion] [Option...]
BESCHREIBUNG
hwclock ist ein Administrationswerkzeug für die verschiedenen Uhren. Es kann die aktuelle
Hardware-Uhrzeit anzeigen, die Hardware-Uhr auf eine angegebene Zeit stellen, die Hardware-Uhr nach der
Systemzeit stellen oder umgekehrt, eine Hardware-Uhr-Abweichung ausgleichen, die Zeitskala der Systemuhr
korrigieren, die Zeitzone des Kernels, die NTP-Zeitskala und die Epoche (nur Alpha) setzen und zukünftige
Hardware-Uhrwerte, basierend auf der Abweichungsrate, vorhersagen.
Seit v2.26 gibt es wichtige Änderungen an der Funktion --hctosys, der Option --directisa und eine neue
Option --update-drift wurde hinzugefügt. Lesen Sie die entsprechenden Beschreibungen unten.
FUNKTIONEN
Die folgenden Funktionen schließen sich gegenseitig aus, nur eine kann ausgewählt werden. Die Vorgabe ist
--show, falls keine angegeben wurde.
-a, --adjust
fügt Zeit zur Hardware-Uhr hinzu oder zieht diese ab, um eine systematische Abweichung seit dem
letzten Setzen oder Anpassen der Hardware-Uhr auszugleichen. Siehe die nachfolgende Erklärungen unter
Die Adjust-Funktion.
--getepoch; --setepoch
Diese Funktionen sind nur für Alpha-Maschinen. Sie sind nur durch den Linux-Kernel-RTC-Treiber
verfügbar.
Sie werden verwandt, um den Kernel-Wert der Hardware-Uhr-Epoche zu lesen und zu setzen. Epoche ist
das Jahr, auf dass sich der Nullwert der Hardware-Uhr bezieht. Wenn das BIOS der Maschine zum
Beispiel die Konvention verwenden, dass die Jahreszählung in der Hardware-Uhr die Anzahl der vollen
Jahre seit 1952 enthält, dann muss der Epochenwert der Hardware-Uhr des Kernels auf 1952 gesetzt
werden.
Die Funktion --setepoch benötigt die Option --epoch, um das Jahr festzulegen. Beispiel:
hwclock --setepoch --epoch=1952
Der RTC-Treiber versucht, den korrekten Wert der Epoche zu raten, daher kann es nicht notwendig sein,
ihn anzugeben.
Dieser Epochenwert wird verwendet, wenn hwclock die Hardware-Uhr auf einer Alpha-Maschine ausliest
oder stellt. Für ISA-Maschinen verwendet der Kernel die feste Hardware-Uhr-Epoche 1900.
--param-get=Parameter; --param-set=Parameter=Wert
liest und setzt die Parameter der Echtzeituhr (RTC). Dies dient beispielsweise der Ermittlung der
verfügbaren Funktionen der Echtzeituhr oder dem Setzen des »Backup Switchover Mode«.
Der Parameter ist entweder ein numerischer RTC-Parameterwert (siehe die Kernel-Datei
include/uapi/linux/rtc.h) oder ein Alias. Mit --help erhalten Sie eine Liste gültiger Aliase. Wenn
dem Parameter und dem Wert 0x vorangestellt ist, werden diese als hexadezimal interpretiert,
ansonsten als dezimal.
--predict
sagt basierend auf der mit der Option --date angegebene Zeit und der Information in /etc/adjtime
vorher, was die Hardware-Uhr in der Zukunft anzeigen wird. Dies ist zum Beispiel nützlich, um
Abweichungen zu berücksichtigen, wenn das Hardware-Uhr-Aufwachen (d.h. ein Alarm) eingerichtet wird.
Siehe rtcwake(8).
Verwenden Sie diese Funktion nicht, falls die Hardware-Uhr durch irgendetwas anderes als den Befehl
hwclock des aktuellen Betriebssystems verändert wird, wie dem »11-Minuten-Modus« oder durch das
Starten eines anderen Betriebssystems.
-r, --show; --get
liest die Hardware-Uhr und schreibt ihre Zeit in die Standardausgabe im ISO 8601-Format. Die
angezeigte Zeit ist stets die lokale Zeit, selbst wenn Sie die Hardware-Uhr auf die Weltzeit (UTC)
eingestellt haben, siehe die Option --localtime.
Die Anzeige der Hardware-Uhrzeit ist die Vorgabe, falls keine Funktion angegeben ist.
Die Funktion --get wendet auch Korrekturen für die Abweichung auf die eingelesene Zeit an, basierend
auf Informationen aus /etc/adjtime. Verwenden Sie diese Funktion nicht, falls die Hardware-Uhr von
irgendetwas anderem außer dem Befehl hwclock des aktuellen Betriebssystems verändert wird, wie dem
»11-Minuten-Modus« oder vom Dual-Boot eines anderen Betriebssystems.
-s, --hctosys
stellt die Systemuhr aus der Hardware-Uhr. Die aus der Hardware-Uhr eingelesene Zeit wird bezüglich
der systematischen Abweichung ausgeglichen, bevor die Systemuhr gestellt wird. Lesen Sie die
Diskussion weiter unten, unter Die Adjust-Funktion.
Die Systemzeit muss in der UTC−Zeitskala gehalten werden, damit Anwendungen im Zusammenhang mit der
für das System konfigurierten Zeitzone arbeiten. Falls die Hardware-Uhr in der lokalen Zeit gehalten
wird, dann muss die daraus gelesene Zeit in die UTC−Zeitskala verschoben werden, bevor sie zum Setzen
der Systemuhr verwendet wird. Die Funktion --hctosys erledigt dies basierend auf den Informationen in
der Datei /etc/adjtime oder aus den Befehlszeilenargumenten --localtime und --utc. Hinweis: Es wird
keine Sommerzeitanpassung durchgeführt. Siehe die Diskussion weiter unten unter LOKAL vs. UTC.
Der Kernel hält auch einen Zeitzonenwert, die Funktion --hctosys setzt ihn auf den für das System
konfigurierten Wert. Die Systemzeitzone wird durch die TZ-Umgebungsvariable oder die Datei
/etc/localtime konfiguriert, wie tzset(3) sie interpretieren würde. Das veraltete Feld tz_dsttime des
Kernel-Zeitzonenwerts wird auf Null gesetzt. Details zur ehemaligen Bedeutung dieses Feldes finden
Sie in settimeofday(2).
Wird die Funktion --hctosys durch Verwendung in einem Systemstartskript der erste Aufrufer von
settimeofday(2), dann wird über die Kernelvariable persistent_clock_is_local der NTP
»11-Minuten−Modus« gesetzt. Falls die Hardware-Uhr-Zeitskalenkonfiguration geändert wird, ist ein
Systemneustart notwendig, um den Kernel zu informieren. Lesen Sie die Diskussion weiter unten unter
Automatischer Abgleich der Hardware-Uhr durch den Kernel.
Dies ist eine gute Funktion für die Ausführung in einem der Startskripte des Systems bevor die
Dateisysteme im Lese-/Schreibmodus eingehängt werden.
Diese Funktion sollte niemals auf einem laufenden System verwendet werden. Springende Systemzeit
führt zu Problemen, wie fehlerhaften Dateisystemzeitstempeln. Falls auch etwas die Hardware-Uhr
geändert hat, wie NTPs »11-Minuten-Modus«, dann wird --hctosys die Zeit durch Berücksichtigung der
Abweichungsausgleichung inkorrekt einstellen.
Die Abweichungsausgleichung kann durch Setzen des Abweichungsfaktors in /etc/adjtime auf Null
unterdrückt werden. Diese Einstellung ist dauerhaft, solange wie die Option --update-drift nicht
zusammen mit --systohc beim Herunterfahren des Systems (oder irgendwann sonst) verwendet wird. Eine
andere Möglichkeit, dies zu unterdrücken, besteht in der Option --noadjfile beim Einsatz der Funktion
--hctosys. Eine dritte Methode besteht im Löschen der Datei /etc/adjtime. hwclock wird dann
standardmäßig die UTC-Zeitskala für die Hardware-Uhr verwenden. Falls die Hardware-Uhr in lokaler
Zeit läuft, muss das in dieser Datei definiert werden. Dies kann durch Aufruf von hwclock --localtime
--adjust erfolgen. Wenn die Datei nicht vorhanden ist, wird dieser Befehl nicht wirklich die Uhr
anpassen, sondern wird die Datei mit der konfigurierten lokalen Zeit und einem Abweichungsfaktor von
Null anlegen.
Eine Bedingung, unter der die Abweichungskorrektur von hwclock verhindert werden sollte, könnte beim
Dualstart von mehreren Betriebssystemen vorliegen. Falls, während diese Instanz von Linux angehalten
ist, ein anderes Betriebssystem die Hardware-Uhr stellt, dann wird die Abweichungskorrektur nach dem
Start dieser Instanz bei der Anwendung inkorrekt sein.
Damit die Abweichungskorrektur von hwclock korrekt funktioniert, ist es zwingend, dass nichts die
Hardware-Uhr ändert, während die Linux-Instanz nicht läuft.
--set
setzt die Hardware-Uhr auf die durch die Option --date angegebene Zeit und aktualisiert die
Zeitstempel in /etc/adjtime. Mit der Option --update-drift wird der Abweichungsfaktor (neu)
berechnet. Versuchen Sie, die Option wegzulassen, falls --set fehlschlägt. Siehe --update-drift
unten.
--systz
Dies ist eine Alternative zu der Funktion --hctosys, die nicht die Hardware-Uhr liest und nicht die
Systemzeit setzt. Entsprechend gibt es auch keine Korrektur der Abweichung. Sie ist für
Hochfahrskripte auf Systemen mit Kerneln höher als 2.6 gedacht, bei denen Sie wissen, dass die
Systemuhr bereits vom Kernel während des Systemstarts aus der Hardware-Uhr gesetzt wurde.
Dies führt die folgenden Dinge aus, die weiter oben in der Funktion --hctosys beschrieben sind:
• Korrigiert die Systemuhrzeitskala auf UTC wie benötigt. Anstatt aber dies durch Setzen der
Systemuhr zu erreichen, informiert hwclock einfach den Kernel und der kümmert sich um die
Änderung.
• Setzt die NTP »11-Minuten-Modus«-Zeitskala des Kernels
• Setzt die Zeitzone des Kernels
Die ersten zwei sind nur beim ersten Aufruf von settimeofday(2) nach dem Systemstart verfügbar.
Konsequenterweise ergeben diese Optionen nur bei der Verwendung in Systemstartskripten Sinn. Falls die
Hardware-Uhr-Zeitskalenkonfiguration geändert wird, ist ein Systemneustart notwendig, um den Kernel zu
informieren.
-w, --systohc
setzt die Hardware-Uhr aus der Systemuhr und aktualisiert die Zeitstempel in /etc/adjtime. Mit der
Option --update-drift wird auch der Abweichungsfaktor (neu) berechnet. Versuchen Sie es ohne die
Option, falls --systohc fehlschlägt. Siehe --update-drift weiter unten.
-h, --help
zeigt einen Hilfetext an und beendet das Programm.
-V, --version
zeigt Versionsinformationen an und beendet das Programm.
OPTIONEN
--adjfile=Dateiname
setzt den vorgegebenen Dateipfad /etc/adjtime außer Kraft.
--date=Datumszeichenkette
Diese Option muss zusammen mit den Funktionen --set oder --predict verwandt werden, andernfalls wird
sie ignoriert.
hwclock --set --date='16:45'
hwclock --predict --date='2525-08-14 07:11:05'
Das Argument muss in lokaler Zeit sein, selbst wenn Sie Ihre Hardware-Uhr in UTC halten. Siehe die
Option --localtime. Daher sollte das Argument keine Zeitzoneninformationen enthalten. Es sollte auch
keine relative Zeit wie »+5 minutes« sein, da die Genauigkeit von hwclock von dem Zusammenhang
zwischen dem Wert des Arguments und dem Zeitpunkt, zu dem die Eingabetaste gedrückt wird, abhängt.
Sekundenbruchteile werden ohne Rückmeldung abgeschnitten. Diese Option kann viele Zeit- und
Datumsformate erkennen, aber die vorhergehenden Parameter sollten beachtet werden.
--delay=Sekunden
Diese Option erlaubt es, die intern verwandte Verzögerung beim Setzen der Uhrzeit zu ändern. Die
Vorgabe ist 0.5 (500 ms) für rtc_cmos, für andere RTC-Typen ist die Verzögerung 0. Falls der RTC-Typ
nicht (aus Sysfs) bestimmt werden kann, dann ist die Vorgabe aufgrund der Rückwärtskompatibilität
auch 0.5.
Die Standardverzögerung von 500 ms basiert auf der häufig verwandten, MC146818A-kompatiblen
(X86-)Hardwareuhr. Die Hardwareuhr kann nur auf ganzzahlige Zeiten plus eine halbe Sekunde gesetzt
werden. Die Ganzzahlzeit ist notwendig, da es keine Schnittstelle gibt, um Sekundenbruchteile zu
setzen oder abzufragen. Die zusätzliche halbe Sekunde Verzögerung erfolgt, da die Hardwareuhr sich
auf die folgende Sekunde genau 500 ms nach dem Setzen der neuen Zeit aktualisiert. Unglücklicherweise
ist dieses Verhalten hardwareabhängig und in einigen Fällen wird eine andere Verzögerung benötigt.
-D, --debug
Verwenden Sie --verbose. Die Option --debug ist veraltet und kann in einer zukünftigen
Veröffentlichung einer neuen Verwendung zugeführt oder entfernt werden.
--directisa
Diese Option ist auf ISA-kompatiblen Maschinen (einschließlich x86 und x86_64) von Bedeutung. Auf
anderen Maschinen hat sie keine Auswirkungen. Diese Option weist hwclock explizit an, E/A−Anweisungen
für den Zugriff auf die Hardware-Uhr vorzunehmen. Ohne diese Option versucht hwclock, die
RTC-Gerätdatei zu verwenden, wobei angenommen wird, dass diese mit dem Linux-RTC-Gerätetreiber läuft.
Seit v2.26 wird er nicht mehr automatisch directisa verwenden, wenn der RTC-Treiber nicht verfügbar
ist. Dies führte zu unsicheren Bedingungen, die es erlaubten, dass zwei Prozesse auf die Hardware-Uhr
gleichzeitig zugreifen konnten. Direkter Hardware-Zugriff aus dem Benutzerraum sollte nur zum Testen,
zur Fehlersuche und als letzte Rettung, wenn alle anderen Methoden fehlschlagen, verwendet werden.
Siehe die Option --rtc.
--epoch=Jahr
Diese Option ist notwendig, wenn die Funktion --setepoch verwendet wird. Das minimale Jahr ist 1900.
Das Maximum ist systemabhängig (ULONG_MAX - 1).
-f, --rtc=Dateiname
Setzt den Vorgabe-RTC-Dateinamen von hwclock außer Kraft. Anderenfalls wird der erste aus der
folgenden Liste (in dieser Reihenfolge) verwendet: /dev/rtc0, /dev/rtc, /dev/misc/rtc. Für IA-64:
/dev/efirtc /dev/misc/efirtc
-l, --localtime; -u, --utc
zeigt an, auf welche Zeitskala die Hardware-Uhr gesetzt ist.
Die Hardware-Uhr kann konfiguriert sein, entweder UTC oder die lokale Zeitskala zu verwenden,
allerdings gibt es nichts in der Uhr, das angibt, welche der Varianten gewählt wurde. Die Optionen
--localtime und --utc übergeben diese Information an den Befehl hwclock. Falls Sie das Falsche
angeben (oder keines angeben und die falsche Voreinstellung nehmen), werden sowohl das Setzen als
auch das Lesen der Hardware-Uhr inkorrekt sein.
Falls Sie weder --utc noch --localtime angeben, dann wird die zuletzt mit der Setzen-Funktion (--set,
--systohc oder --adjust) verwendete benutzt, wie dies in /etc/adjtime aufgezeichnet ist. Falls die
adjtime-Datei nicht existiert, wird UTC als Vorgabe verwendet.
Hinweis: Änderungen durch Sommerzeit-/Winterzeit-Wechsel können inkonsistent sein, falls die
Hardware-Uhr in lokaler Zeit betrieben wird. Lesen Sie die Diskussion weiter unten unter LOKAL vs.
UTC.
--noadjfile
deaktiviert die von /etc/adjtime bereitgestellten Leistungen. hwclock liest oder schreibt nicht in
diese Datei, wenn diese Option angegeben ist. Mit dieser Option müssen entweder --utc oder
--localtime angegeben werden.
--test
ändert tatsächlich nichts am System, d.h. die Uhren oder /etc/adjtime (diese Option impliziert
--verbose).
--update-drift
aktualisiert den Abweichungsfaktor der Hardware-Uhr in /etc/adjtime. Sie kann nur zusammen mit --set
oder --systohc verwendet werden.
Zwischen Einstellungen ist minimal ein Abstand von vier Stunden notwendig. Damit werden ungültige
Berechnungen vermieden. Je länger die Periode, desto präziser wird der sich ergebende
Abweichungsfaktor sein.
Diese Option wurde in v2.26 hinzugefügt, da typischerweise auf Systemen beim Herunterfahren hwclock
--systohc aufgerufen wird. Mit dem alten Verhalten würde dabei automatisch der Abweichungsfaktor
(neu) berechnet werden, wodurch mehrere Probleme entstanden:
• Wird NTP mit einem »11-Minuten-Modus«-Kernel verwandt, würde der Abweichungsfaktor auf fast Null
verfremdet.
• Es würde nicht die Verwendung von »kalter«-Abweichungskorrektur erlauben. Bei den meisten
Konfigurationen führt die »kalte« Abweichungskorrektur zu besseren Ergebnissen. Kalt bedeutet,
wenn die Maschine ausgeschaltet ist, was eine wesentliche Auswirkung auf den Abweichungsfaktor
haben kann.
• (Neu-)Berechnung des Abweichungsfaktors bei jedem Herunterfahren führt zu suboptimalen
Ergebnissen. Führen beispielsweise kurzzeitige Bedingungen dazu, dass die Maschine ungewöhnlich
heiß wird, wäre die Abweichungsfaktorberechnung außerhalb des Gültigkeitsbereichs.
• Signifikant erhöhte System-Runterfahrzeiten (bei v2.31 wird die RTC nicht gelesen, wenn
--update-drift nicht verwandt wird).
Die Berechnung des Abweichungsfaktors durch hwclock ist ein guter Start, aber für optimale Ergebnisse
wird wahrscheinlich die Datei /etc/adjtime direkt bearbeitet werden müssen. Bei den meisten
Konfigurationen braucht die Abweichung nicht mehr verändert zu werden, sobald der optimale
Abweichungsfaktor erstellt wurde. Daher wurde das alte Verhalten, die Abweichung automatisch (neu) zu
berechnen, geändert und benötigt nun dafür eine Option. Lesen Sie die Diskussion weiter unten unter Die
Adjust-Funktion.
Diese Option benötigt die Hardwareuhr vor ihrem Setzen. Falls sie nicht gelesen werden kann, wird diese
Option zum Fehlschlag der Setzen-Funktion führen. Dies kann beispielsweise passieren, falls die
Hardwareuhr durch einen Stromausfall beschädigt ist. In diesem Fall muss die Uhr zuerst ohne diese Option
gesetzt werden. Abgesehen davon, dass sie nicht funktioniert, wäre der daraus resultierende
Abweichungsfaktor sowieso ungültig.
-v, --verbose
zeigt mehr Details über die internen Vorgänge von hwclock an.
ANMERKUNGEN
Uhren in einem Linux-System
Es gibt zwei Arten von Datum-Zeit-Uhren:
Die Hardware-Uhr: Diese Uhr ist ein unabhängiges Hardware-Gerät, mit seinem eigenen Energiebereich
(Batterie, Kondensatoren, usw.), das läuft, wenn die Maschine ausgeschaltet oder sogar vom Netz getrennt
ist.
Auf einem ISA-kompatiblen System wird diese Uhr als Teil des ISA-Standards spezifiziert. Ein
Steuerprogramm kann diese Uhr nur in ganzen Sekunden stellen oder auslesen, aber es kann auch die
Signalübergänge der Ein-Sekunden-Impulse erkennen, so dass die Uhr über virtuell unendliche Präzision
verfügt.
Diese Uhr wird allgemein die Hardware-Uhr, die Echtzeituhr, die RTC, die BIOS-Uhr oder die CMOS-Uhr
genannt. Der Begriff Hardware-Uhr wurde für hwclock gewählt. Der Linux-Kernel bezeichnet sie auch als
beständige Uhr.
Einige Nicht-ISA-Systeme haben ein paar Echtzeituhren, wobei nur eine davon ihre eigene Energieversorgung
hat. Ein sehr energiesparender externer I²C- oder SPI-Uhrchip könnte mit einer Stützbatterie als
Hardware-Uhr fungieren, um eine funktionellere integrierte Echtzeituhr zu initialisieren, die für die
meisten anderen Zwecke verwendet wird.
Die Systemuhr: Diese Uhr ist Teil des Linux-Kernels und wird durch einen Timer-Interrupt gesteuert (auf
einer ISA-Maschine ist der Timer-Interrupt Teil des ISA-Standards). Sie ist nur von Bedeutung, solange
Linux auf der Maschine läuft. Die Systemzeit wird als die Anzahl der Sekunden seit dem 1. Januar 1970 um
00:00:00 Uhr Weltzeit ausgedrückt, oder anders formuliert, die Anzahl der seit 1969 UTC vergangenen
Sekunden. Die Systemzeit ist dennoch keine Ganzzahl. Sie hat virtuell unbegrenzte Präzision.
Die Systemzeit ist die Zeit, auf die es ankommt. Der grundlegende Zweck der Hardware-Uhr in einem
Linux-System ist die Erhaltung der Zeit, wenn Linux nicht läuft, so dass die Systemzeit beim Systemstart
daraus initialisiert werden kann. Beachten Sie, dass in DOS, wofür der ISA-Standard entworfen wurde, die
Hardware-Uhr die einzig verfügbare Echtzeituhr ist.
Es ist wichtig, dass die Zählung der Systemzeit nicht unterbrochen wird, zum Beispiel wenn Sie mit dem
Befehl date(1) die Systemzeit setzen, während das System läuft. Sie können dennoch im laufenden Betrieb
mit der Hardware-Uhr tun, was Sie wollen, und beim nächsten Linux-Start wird die Zeit der Hardware-Uhr
entsprechend angepasst. Hinweis: Derzeit ist dies auf den meisten Systemen nicht möglich, da beim
Herunterfahren hwclock --systohc aufgerufen wird.
Die Zeitzone des Linux-Kernels wird durch hwclock gesetzt. Aber lassen Sie sich nicht in die Irre führen
– beinahe niemand interessiert sich dafür, was der Kernel meint, in welcher Zeitzone er sich befindet.
Stattdessen müssen Programme, für die die Zeitzone wichtig ist (um Ihnen beispielsweise die lokale Zeit
anzuzeigen), fast immer einen etwas traditionelleren Weg wählen, um die Zeitzone zu ermitteln: Sie
benutzen die TZ-Umgebungsvariable oder die Datei /etc/localtime, wie in der Handbuchseite zu tzset(3)
erklärt. Jedoch nutzen einige Programme und Teile des Linux-Kernels dessen Zeitzonenwert, zum Beispiel
Dateisysteme. Ein Beispiel hierfür ist das vfat-Dateisystem. Ist der Zeitzonenwert im Kernel falsch
gesetzt, werden vom vfat-Dateisystem falsche Zeitstempel gemeldet und gesetzt. Ein weiteres Beispiel ist
der NTP-11-Minuten-Modus-Modus des Kernels. Falls der Zeitzonenwert des Kernels und/oder die Variable
persistent_clock_is_local falsch ist, dann wird die Hardware durch den 11-Minuten-Modus-Modus falsch
gesetzt. Lesen Sie hierzu die Diskussion weiter unten, unter Automatischer Abgleich der Hardware-Uhr
durch den Kernel.
hwclock setzt den Kernel-Zeitzonenwert auf den durch die Umgebungsvariable TZ oder aus /etc/localtime mit
den Funktionen --hctosys oder --systz angegebenen Wert.
Der Zeitzonenwert des Kernels besteht aus zwei Teilen: erstens dem Feld »tz_minuteswest«, das die Anzahl
der Minuten angibt, die die lokale Zeit (nicht an Sommer-/Winterzeit angepasst) gegenüber der Weltzeit
zurückbleibt, und zweitens dem Feld »tz_dsttime«, welches angibt, ob am entsprechenden Ort gerade Sommer-
oder Winterzeit herrscht. Dieses zweite Feld wird unter Linux nicht genutzt und wird stets auf 0 gesetzt.
Siehe auch settimeofday(2).
Zugriffsmethoden auf Hardware-Uhren
hwclock verwendet viele verschiedene Arten, die Hardware-Uhr-Werte zu ermitteln und zu setzen. Der
normale Weg besteht in E/A zu der besondere Datei des RTC-Geräts. Dabei wird angenommen, dass diese vom
RTC-Treiber betrieben wird. Auch sind Linux-Systeme, die das RTC-Konzept mit Udev verwenden, in der Lage,
mehrere Hardware-Uhren zu unterstützen. Damit könnte die Notwendigkeit entstehen, das Vorgabe-RTC-Gerät
mit der Option --rtc außer Kraft zu setzen.
Allerdings ist diese Methode nicht immer verfügbar, da ältere Systeme über keinen RTC-Treiber verfügen.
Auf diesen Systemen hängt die Art des Zugriffs auf die Hardware-Uhr von der Art der Systemhardware ab.
Auf einem ISA-kompatiblen System kann hwclock direkt über Ein- und Ausgaben der Ports 0x70 und 0x71 auf
die CMOS-Speicherregister zugreifen, welche die Uhr darstellen. Es werden E/A-Anweisungen verwendet, was
konsequenterweise nur funktionieren kann, wenn diese mit der effektiven Benutzerkennung des Superusers
aufgerufen werden. Diese Methode kann durch Angabe der Option --directisa festgelegt werden.
Dies ist eine recht armselige Methode, auf die Uhr zuzugreifen, vor allem deshalb, weil Programme auf
Anwenderebene generell nicht dafür bestimmt sind, direkte E/A-Vorgänge auszuführen und Interrupts zu
deaktivieren. hwclock bietet dies zum Testen, Fehlersuchen und da es auf ISA-kompatiblen Systemen, die
über keinen funktionierenden RTC-Gerätetreiber verfügen, die einzige verfügbare Methode sein könnte.
Die Adjust-Funktion
Die Hardware-Uhr ist üblicherweise nicht sehr genau. Jedoch lässt sich die Genauigkeit recht gut
vorhersagen – sie geht jeden Tag die gleiche Zeit vor oder nach. Dies nennt man die Systemabweichung. Mit
der Funktion --adjust von hwclock können Sie die Systemabweichung der Hardware-Uhr korrigieren.
Es funktioniert folgendermaßen: hwclock verwaltet die Datei /etc/adjtime, in der einige historische
Informationen gespeichert sind. Diese Datei wird adjtime-Datei genannt.
Nehmen wir an, Sie beginnen ohne adjtime-Datei. Sie rufen den Befehl hwclock --set auf, um die
Hardware-Uhr auf die tatsächliche aktuelle Zeit zu stellen. hwclock legt die adjtime-Datei an und
zeichnet darin die Zeit als jene der letzten Kalibrierung der Uhr auf. Fünf Tage später geht die Uhr 10
Sekunden vor, und Sie rufen hwclock --set --update-drift auf, um die Uhr 10 Sekunden zurückzustellen.
hwclock aktualisiert die adjtime-Datei, zeichnet wiederum die aktuelle Zeit als den Zeitpunkt der letzten
Kalibrierung auf, wobei diesmal 2 Sekunden pro Tag als systematische Abweichung protokolliert werden. 24
Stunden später rufen Sie den Befehl hwclock --adjust auf. hwclock befragt die adjtime-Datei und stellt
fest, dass die Uhr, wenn sie nicht korrigiert wird, 2 Sekunden pro Tag vorgeht. So zieht es die 2
Sekunden von der Zeit der Hardware-Uhr ab, da die Uhr genau 24 Stunden nicht korrigiert wurde. Die
aktuelle Zeit wird auch wieder als die Zeit der letzten Kalibrierung aufgezeichnet. Noch einmal 24
Stunden später funktioniert der Befehl hwclock --adjust wieder auf die gleiche Weise: hwclock zieht 2
Sekunden ab und aktualisiert die adjtime−Datei mit der aktuellen Zeit als letztem Kalibrierungszeitpunkt
der Uhr.
Wenn Sie die Option -update-drift mit --set oder --systohc verwenden, wird die automatische
Abweichungsrate durch Vergleich der vollständig abweichungskorrigierten Hardware-Uhr mit der jetzt
gesetzten Zeit (neu) berechnet. Daraus wird die 24-Stunden-Abweichungsrate basierend auf dem letzten
kalibrierten Zeitstempel aus der Adjtime-Datei abgeleitet. Dieser aktualisierte Abweichungsfaktor wird
dann in /etc/adjtime gespeichert.
Kleinere Fehler schleichen sich beim Stellen der Hardware-Uhr ein, daher unterlässt --adjust Korrekturen
von weniger als einer Sekunde. Wenn Sie zu einem späteren Zeitpunkt erneut die Uhr stellen wollen, wird
die aufgesammelte Abweichung nun mehr als eine Sekunde betragen und --adjust führt die Korrektur
einschließlich eines Bruchanteils aus.
hwclock --hctosys verwendet auch die Daten Adjtime-Datei, um den Wert aus der Hardware-Uhr auszugleichen,
bevor es die Systemuhr stellt. Es teilt nicht die 1-Sekunden-Begrenzung von --adjust und wird
Abweichungen von Sekundenbruchteilen sofort korrigieren. Es ändert weder die Hardware-Uhr noch die
Adjtime-Datei. Dies könnte die Notwendigkeit von --adjust beseitigen, außer etwas anderes auf dem System
benötigt den Abgleich der Hardware-Uhr.
Die Datei Adjtime
Sie wurde wegen ihres früheren ausschließlichen Zwecks der Steuerung des Abgleichs so benannt und enthält
außerdem Informationen, die hwclock für spätere Aufrufe speichert.
Die adjtime-Datei verwendet folgendes Format, in ASCII:
Zeile 1: drei Zahlen, durch Leerzeichen getrennt: 1) die systematische Abweichung in Sekunden pro Tag als
dezimale Fließkommazahl; 2) die sich ergebende Anzahl der Sekunden seit 1969 Weltzeit gemäß der letzten
Anpassung oder Kalibrierung als dezimale Ganzzahl; 3) Null (zwecks Kompatibilität zu clock(8)) als
dezimale Gleitkommazahl.
Zeile 2: eine Zahl: die sich ergebende Anzahl der Sekunden seit 1969 Weltzeit gemäß der letzten
Kalibrierung. Dies ist Null, falls noch keine Kalibrierung ausgeführt wurde oder eine frühere
Kalibrierung fehlschlug (zum Beispiel wurde die Hardware-Uhr seit der Kalibrierung zwar gefunden,
enthielt aber keine gültige Zeit). Dies ist eine dezimale Ganzzahl.
Zeile 3: »UTC« oder »LOCAL«. Dies gibt an, ob die Hardware-Uhr auf lokale Zeit oder Weltzeit eingestellt
ist. Sie können diesen Wert stets mit den Befehlszeilenoptionen zu hwclock außer Kraft setzen.
Sie können eine adjtime-Datei, die früher bereits mit dem Programm clock(8) genutzt wurde, auch mit
hwclock verwenden.
Automatischer Abgleich der Hardware-Uhr durch den Kernel
Es gibt auf einigen Systemen einen weiteren Weg, die Hardware-Uhr synchron zu halten. Der Linux-Kernel
verfügt über einen Modus, in dem in Abständen von 11 Minuten die Systemzeit in die Hardware-Uhr kopiert
wird. Dieser Modus wird beim Kompilieren ausgewählt, daher werden nicht alle Kernel über diese Fähigkeit
verfügen. Dieser Modus ist sinnvoll, wenn Sie etwas Fortschrittliches wie NTP verwenden, um die Systemuhr
synchron zu halten. (NTP bezeichnet die Synchronisation der Systemzeit entweder über einen Zeitserver im
Netzwerk oder über eine an Ihrem System angeschlossene Funkuhr, siehe RFC 1305.)
Falls der Kernel mit der Option »11-Minuten-Modus« übersetzt ist, wird er aktiv sein, wenn sich die
Uhrdisziplin des Kernels in einem synchronisierten Zustand befindet. In diesem Zustand ist das Bit 6 (das
Bit, das mit der Maske 0x0040 gesetzt wird) der Kernelvariablen time_status nicht gesetzt. Der Wert wird
als »Status«-Zeile der Befehle adjtimex --print oder ntptime ausgegeben.
Es bedarf eines Einflusses von außen, wie des NTP-Daemons, um die Uhrdisziplin des Kernels in einen
synchronisierten Status zu bringen und damit den »11-Minuten-Modus« zu aktivieren. Dieser kann durch die
Ausführung von allem, die die Systemuhr auf die althergekommene Art setzt, wie hwclock --hctosys, wieder
ausgeschaltet werden. Falls der NTP-Daemon allerdings noch läuft, wird er den »11-Minuten-Modus« beim
nächsten Synchronisieren der Systemuhr wieder einschalten.
Falls Ihr System mit aktiviertem »11-Minuten-Modus« läuft, könnte die Verwendung von entweder --hctosys
oder --systz in den Systemstartskripten notwendig sein, insbesondere falls die Hardware-Uhr auf die
lokale Zeitskala konfiguriert ist. Falls der Kernel nicht informiert ist, unter welcher Zeitskala die
Hardware-Uhr läuft, könnte er sie mit der falschen verfremden. Der Kernel verwendet standardmäßig UTC.
Der erste Benutzerraumbefehl, der die Systemuhr setzt, informiert den Kernel, welche Zeitskala die
Hardware-Uhr verwendet. Dies passiert über die Kernelvariable persistent_clock_is_local. Falls --hctosys
oder --systz zuerst ist, wird es diese Variable entsprechend der Adjtime-Datei oder dem geeigneten
Befehlszeilenargument setzen. Beachten Sie, dass der Einsatz dieser Fähigkeit erfordert, dass bei
Änderung der Hardware-Uhr-Zeitskalenkonfiguration ein Systemneustart zur Information des Kernels benötigt
wird.
hwclock --adjust sollte nicht zusammen mit NTPs »11-Minuten-Modus« verwendet werden.
Jahrhundertwert der ISA-Hardware-Uhr
Es gibt eine Art von Standard, der das CMOS-Speicherbyte 50 auf einer ISA-Maschine als Anzeiger für das
aktuelle Jahrhundert verwendet. hwclock nutzt oder setzt dieses Byte nicht, da es einige Maschinen gibt,
die das Byte nicht auf diese Weise definieren und es sowieso unnötig ist. Das year-of-century leistet
gute Arbeit beim Ermitteln des aktuellen Jahrhunderts.
Falls Sie einen echten Anwendungsfall für das CMOS-Century-Byte haben, kontaktieren Sie den Betreuer von
hwclock, eine Option könnte hier zweckdienlich sein.
Beachten Sie, dass dieser Abschnitt nur relevant ist, wenn Sie die »Direct ISA«-Methode für den Zugriff
auf die Hardware-Uhr verwenden. ACPI bietet eine standardisierte Zugriffsmöglichkeit auf die
Jahrhundertwerte an, sofern diese von der Hardware unterstützt werden.
DATUM-ZEIT-KONFIGURATION
Zeit ohne externe Synchronisation erhalten
Diese Diskussion basiert auf den folgenden Annahmen:
• Es läuft nichts, das die Echtzeituhren ändert, wie ein NTP-Daemon oder ein Cron-Job.
• Die Systemzeitzone ist für die korrekte lokale Zeit konfiguriert. Siehe unten unter POSIX kontra
»KORREKT«.
• Früh während des Systemstarts wird Folgendes in dieser Reihenfolge aufgerufen: adjtimex --tick Wert
--frequency Wert hwclock --hctosys
• Während des Herunterfahrens wird folgendes aufgerufen: hwclock --systohc
• Systeme ohne adjtimex können ntptime verwenden.
Egal, ob eine Präzisionzeit mit einem NTP-Daemon verwaltet wird oder nicht, ist es sinnvoll, das System
so konfigurieren, dass es allein eine vernünftig gute Datum-Uhrzeit hält.
Im ersten Schritt dafür muss ein klares Verständnis des Gesamtbildes erreicht werden. Es gibt zwei
komplett getrennte Hardwaregeräte, die alleine in ihrer eigenen Geschwindigkeit laufen und von der
»korrekten« Zeit mit ihrer eigenen Rate abweichen. Die Methoden und Software für die Abweichungskorrektur
unterscheiden sich für beide. Allerdings sind die meisten Systeme so konfiguriert, dass die beiden Uhren
beim Systemstart und -herunterfahren die Werte austauschen. Dadurch werden die Fehlerkorrekturwerte der
einzelnen Geräte zwischen beiden hin und her übertragen. Wird versucht, nur bei einem von ihnen eine
Abweichungskorrektur vorzunehmen, wird die Abweichung des anderen Geräts darübergelegt.
Dieses Problem kann bei Konfiguration der Abweichung der Systemuhr vermieden werden, indem die Maschine
nicht heruntergefahren wird. Dies und der Tatsache, dass die gesamte Präzision von hwclock
(einschließlich der Berechnung des Abweichungsfaktors) von der Korrektheit der Systemuhrrate abhängt,
bedeutet, dass die Konfiguration der Systemuhr zuerst erfolgen sollte.
Die Abweichung der Systemuhr wird mit den Optionen tick und --frequency des Befehls adjtimex(8)
korrigiert. Diese zwei Optionen arbeiten zusammen: »tick« ist die grobe und »frequency« die feine
Anpassung. (Für Systeme, die kein adjtimex-Paket haben, kann eventuell stattdessen ntptime -f ppm
verwendet werden.)
Einige Linux-Distributionen versuchen, die Abweichung der Systemuhr mit der Vergleichsaktion von adjtimex
automatisch zu berechnen. Der Versuch, eine abweichende Uhr mittels einer anderen abweichenden Uhr als
Referenz zu korrigieren, gleicht dem Versuch eines Hundes, seinen eigenen Schwanz zu fangen. Es mag
irgendwann von Erfolg gekrönt sein, aber vorher ist großer Aufwand und viel Frust involviert. Diese
Automatisierung mag eine Verbesserung gegenüber keiner Konfiguration sein, aber optimale Ergebnisse zu
erwarten, wäre fehlerhaft. Eine bessere Wahl für eine manuelle Konfiguration wäre die Option --log von
adjtimex.
Es mag effizienter sein, einfach die Abweichung der Systemuhr mit sntp oder date -Ins und einem genauen
Zeitstück nachzuverfolgen und dann die Abweichung manuell zu berechnen.
Nach dem Setzen der Tick- und Frequenzwerte fahren Sie mit dem Prüfen und Verfeinern der Anpassungen
fort, bis die Systemuhr eine gute Zeit hält. Siehe adjtimex(2) für weitere Informationen und ein
Beispiel, das die manuelle Abweichungskorrektur zeigt.
Sobald der Takt der Systemuhr sauber ist, widmen Sie sich der Hardware-Uhr.
In der Regel funktioniert die kalte Abweichung in den meisten Fällen am besten. Dies sollte sogar auf
Maschinen zutreffen, die 24/7 laufen und deren normale Auszeit aus einem Systemneustart besteht. In
diesen Fällen stellt der Abweichungsfaktor kaum einen Unterschied dar. Aber in den seltenen Fällen, in
denen die Maschine für eine längere Zeit ausgeschaltet wird, sollte die kalte Abweichung zu besseren
Ergebnissen führen.
Schritte zur Berechnung der kalten Abweichung:
1
Stellen Sie sicher, dass kein NTP-Daemon beim Systemstart gestartet wird.
2
Beim Herunterfahren muss die Zeit der Systemuhr korrekt sein!
3
Fahren Sie das System herunter.
4
Lassen Sie eine ausgedehnte Zeit vergehen, ohne die Hardware-Uhr zu ändern.
5
Starten Sie das System.
6
Verwenden Sie sofort hwclock, um die korrekte Zeit zu setzen, fügen Sie dabei die Option
--update-drift hinzu.
Hinweis: Falls in Schritt 6 --systohc verwendet wird, muss davor die Systemuhr korrekt gesetzt werden
(Schritt 6a).
Die Berechnung des Abweichungsfaktors durch hwclock ist ein guter Start, aber für optimale Ergebnisse
wird wahrscheinlich die Datei /etc/adjtime direkt bearbeitet werden müssen. Fahren Sie mit den Tests fort
und verfeinern Sie den Abweichungsfaktor, bis die Hardware-Uhr beim Start exakt gestellt wird. Um dies zu
überprüfen, stellen Sie zunächst sicher, dass die Systemzeit vor dem Herunterfahren korrekt gesetzt wurde
und verwenden dann sntp oder date -Ins mit der gewünschten Präzision unmittelbar nach dem Start.
LOKAL vs. UTC
Wird die Hardware-Uhr in der lokalen Zeitskala betrieben, führt dies zu inkonsistenten
Sommerzeitergebnissen:
• Falls Linux während des Sommer-/Winterzeitwechsels läuft, wird die in die Hardware-Uhr geschriebene
Zeit für die Änderung angepasst.
• Falls Linux NICHT während des Sommer-/Winterzeitwechsels läuft, wird die von der Hardware-Uhr
gelesene Zeit NICHT für die Änderung angepasst werden.
Die Hardware-Uhr auf einem ISA-kompatiblen System hält nur ein Datum und eine Zeit. Sie kennt weder das
Konzept der Zeitzone noch der Sommer-/Winterzeit. Daher nimmt hwclock, wenn ihm mitgeteilt wird, dass es
in lokaler Zeit läuft, an, dass es sich in der »korrekten« lokalen Zeit befindet und führt keine
Anpassungen für die aus ihr gelesene Zeit durch.
Linux führt den Sommer-/Winterzeitwechsel nur korrekt durch, wenn die Hardware-Uhr in der UTC-Zeitskala
läuft. Dies wird Systemadministratoren erleichtert, da hwclock die lokale Zeit für seine Ausgabe und als
Argument für die Option --date verwendet.
POSIX-Systeme sind wie Linux so entwickelt, dass die Systemuhr in der UTC-Zeitskala läuft. Der Zweck der
Hardware-Uhr liegt darin, die Systemuhr zu initialisieren, daher ergibt ein Betrieb in UTC Sinn.
Linux versucht allerdings, die Tatsache, dass sich die Hardware in der lokalen Zeitskala befindet, zu
berücksichtigen. Dies dient primär dem dualen Systemstart mit älteren Versionen von MS Windows. Seit
Windows 7 soll der Registrierungsschlüssel RealTimeIsUniversal korrekt funktionieren, so dass die
Hardware-Uhr in UTC gehalten werden kann.
POSIX kontra »KORREKT«
Eine Diskussion der Datum/Zeit-Konfiguration wäre allerdings unvollständig, ohne Zeitzonen zu behandeln.
Dies wird gut in tzset(3) abgedeckt. Ein Punkt, für den es keine Dokumentation gibt, ist das »korrekte«
Verzeichnis der Zeitzonendatenbank, manchmal auch tz oder Zoneinfo genannt.
Es gibt zwei getrennte Datenbanken in dem Zoneinfo-System, POSIX und »korrekt«. »Korrekt« (jetzt
Zoneinfo-leaps genannt) enthält Schaltsekunden, POSIX nicht. Um die »korrekte« Datenbank zu verwenden,
muss die Systemuhr auf (UTC + Schaltsekunden) gesetzt sein, was zu (TAI - 10) äquivalent ist. Dies
ermöglicht es, die genaue Anzahl von Sekunden zwischen zwei Daten zu berechnen, wenn dabei ein
Schaltsekundenzeitraum durchlaufen wird. Die Systemuhr wird dann in die korrekte zivile Zeit,
einschließlich UTC, umgewandelt, indem die »korrekten« Zeitzonendateien verwandt werden, die die
Schaltsekunden abziehen. Hinweis: Diese Konfiguration wird als experimentell bezeichnet und hat
bekanntermaßen Probleme.
Um ein System zur Verwendung einer bestimmten Datenbank zu konfigurieren, müssen alle in seinem
Verzeichnis befindliche Dateien in die Wurzel von /usr/share/zoneinfo kopiert werden. Dateien werden nie
vom POSIX- oder »korrekten« Unterverzeichnis benutzt, z.B. TZ='_right/Europe/Dublin'. Diese Gepflogenheit
wurde so üblich, dass die Originalentwickler des Zoneinfo-Projekts den Systemdateibaum restrukturierten,
indem sie die POSIX- und »korrekten« Unterverzeichnisse aus dem Zoeninfo-Verzeichnis und in benachbarte
Verzeichnisse verschoben:
/usr/share/zoneinfo, /usr/share/zoneinfo-posix, /usr/share/zoneinfo-leaps
Unglücklicherweise ändern einige Linux-Distributionen dies in ihren Paketen wieder auf die alte Struktur
zurück. Daher besteht das Problem der Systemadministratoren, die in das »korrekte« Unterverzeichnis
hineingreifen, weiter fort. Dies führt dazu, dass die Systemzeitzone konfiguriert wird, Schaltsekunden zu
beachten, während die Zoneinfo-Datenbank weiterhin so konfiguriert ist, sie auszuschließen. Wenn dann
eine Anwendung wie die »World Clock« die Zeitzonendatei South_Pole benötigt oder ein E-Mail-MTA oder
hwclock die UTC-Zeitzonen-Datei benötigen, holen sie sie von der Wurzel von /usr/share/zoneinfo, da das
so von ihnen erwartet wird. Diese Dateien schließen Schaltsekunden aus, aber die Systemuhr berücksichtigt
sie, wodurch eine falsche Umwandlung hervorgerufen wird.
Der Versuch, Dateien aus diesen getrennten Datenbanken vermischt zu benutzen, wird nicht funktionieren,
da sie von der Systemuhr verlangen, eine andere Zeitskala zu verwenden. Die Zoneinfo−Datenbank muss
entweder gemäß POSIX oder »right« konfiguriert werden, entweder die POSIX oder »korrekte« zu benutzen,
oder indem der Umgebungsvariablen TZDIR ein Datenbankpfad zugewiesen wird.
EXIT-STATUS
Eine der folgenden Rückgabewerte wird zurückgeliefert:
EXIT_SUCCESS ('0' auf POSIX-Systemen)
Erfolgreiche Programmausführung.
EXIT_FAILURE ('1' auf POSIX-Systemen)
Die Aktion ist fehlgeschlagen oder die Befehlssyntax war ungültig.
UMGEBUNGSVARIABLEN
TZ
Falls diese Variable gesetzt ist, hat ihr Wert gegenüber der im System konfigurierten Zeitzone
Vorrang.
TZDIR
Falls diese Variable gesetzt ist, hat ihr Wert gegenüber dem im System konfigurierten
Zeitzonendatenbankverzeichnispfad Vorrang.
DATEIEN
/etc/adjtime
Die Konfiguration und die Zustandsdateien für hwclock. Siehe auch adjtime_config(5).
/etc/localtime
Die Systemzeitzonendatei
/usr/share/zoneinfo/
Das System-Zeitzonen-Datenbankverzeichnis
Gerätedateien, die hwclock für den Zugriff auf die Hardware−Uhr versuchen darf: /dev/rtc0 /dev/rtc
/dev/misc/rtc /dev/efirtc /dev/misc/efirtc
SIEHE AUCH
date(1), adjtime_config(5), adjtimex(8), gettimeofday(2), settimeofday(2), crontab(1p), tzset(3)
AUTOREN
Geschrieben von Bryan Henderson <bryanh@giraffe-data.com>, September 1996, basierend auf dem Programm
clock(8) von Charles Hedrick, Rob Hooft und Harald Koenig. Im Quellcode finden Sie die vollständige
Geschichte einschließlich der Danksagungen.
FEHLER MELDEN
Nutzen Sie zum Melden von Fehlern das Fehlererfassungssystem auf
https://github.com/util-linux/util-linux/issues.
VERFÜGBARKEIT
Der Befehl hwclock ist Teil des Pakets util-linux, welches aus dem Linux-Kernel-Archiv
<https://www.kernel.org/pub/linux/utils/util-linux/> heruntergeladen werden kann.
util-linux 2.39.3 2025-06-05 HWCLOCK(8)