HWCLOCK(8) System-Administration HWCLOCK(8) BEZEICHNUNG hwclock - Zeituhren-Hilfswerkzeug UBERSICHT hwclock [Funktion] [Option...] BESCHREIBUNG hwclock ist ein Administrationswerkzeug fur 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 zukunftige Hardware-Uhrwerte, basierend auf der Abweichungsrate, vorhersagen. Seit v2.26 gibt es wichtige Anderungen an der Funktion --hctosys, der Option --directisa und eine neue Option --update-drift wurde hinzugefugt. Lesen Sie die entsprechenden Beschreibungen unten. FUNKTIONEN Die folgenden Funktionen schliessen sich gegenseitig aus, nur eine kann ausgewahlt werden. Die Vorgabe ist --show, falls keine angegeben wurde. -a, --adjust fugt 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 Erklarungen unter Die Adjust-Funktion. --getepoch; --setepoch Diese Funktionen sind nur fur Alpha-Maschinen. Sie sind nur durch den Linux-Kernel-RTC-Treiber verfugbar. Sie werden verwendet, 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 Jahreszahlung in der Hardware-Uhr die Anzahl der vollen Jahre seit 1952 enthalt, dann muss der Epochenwert der Hardware-Uhr des Kernels auf 1952 gesetzt werden. Die Funktion --setepoch benotigt 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. Fur 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 verfugbaren 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 gultiger 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 nutzlich, um Abweichungen zu berucksichtigen, 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 verandert 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 fur 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 ausser dem Befehl hwclock des aktuellen Betriebssystems verandert 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 bezuglich 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 fur 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 durchgefuhrt. Siehe die Diskussion weiter unten unter LOKAL vs. UTC. Der Kernel halt auch einen Zeitzonenwert, die Funktion --hctosys setzt ihn auf den fur das System konfigurierten Wert. Die Systemzeitzone wird durch die TZ-Umgebungsvariable oder die Datei /etc/localtime konfiguriert, wie tzset(3) sie interpretieren wurde. 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 uber die Kernelvariable persistent_clock_is_local der NTP >>11-Minuten-Modus<< gesetzt. Falls die Hardware-Uhr-Zeitskalenkonfiguration geandert 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 fur die Ausfuhrung in einem der Startskripte des Systems bevor die Dateisysteme im Lese-/Schreibmodus eingehangt werden. Diese Funktion sollte niemals auf einem laufenden System verwendet werden. Springende Systemzeit fuhrt zu Problemen, wie fehlerhaften Dateisystemzeitstempeln. Falls auch etwas die Hardware-Uhr geandert hat, wie NTPs >>11-Minuten-Modus<<, dann wird --hctosys die Zeit durch Berucksichtigung der Abweichungsausgleichung inkorrekt einstellen. Die Abweichungsausgleichung kann durch Setzen des Abweichungsfaktors in /etc/adjtime auf Null unterdruckt 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 Moglichkeit, dies zu unterdrucken, besteht in der Option --noadjfile beim Einsatz der Funktion --hctosys. Eine dritte Methode besteht im Loschen der Datei /etc/adjtime. hwclock wird dann standardmassig die UTC-Zeitskala fur die Hardware-Uhr verwenden. Falls die Hardware-Uhr in lokaler Zeit lauft, 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, konnte beim Dualstart von mehreren Betriebssystemen vorliegen. Falls, wahrend 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 andert, wahrend die Linux-Instanz nicht lauft. --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 fehlschlagt. 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 fur Hochfahrskripte auf Systemen mit Kerneln hoher als 2.6 gedacht, bei denen Sie wissen, dass die Systemuhr bereits vom Kernel wahrend des Systemstarts aus der Hardware-Uhr gesetzt wurde. Dies fuhrt die folgenden Dinge aus, die weiter oben in der Funktion --hctosys beschrieben sind: o Korrigiert die Systemuhrzeitskala auf UTC wie benotigt. Anstatt aber dies durch Setzen der Systemuhr zu erreichen, informiert hwclock einfach den Kernel und der kummert sich um die Anderung. o Setzt die NTP >>11-Minuten-Modus<<-Zeitskala des Kernels o Setzt die Zeitzone des Kernels Die ersten zwei sind nur beim ersten Aufruf von settimeofday(2) nach dem Systemstart verfugbar. Konsequenterweise ergeben diese Optionen nur bei der Verwendung in Systemstartskripten Sinn. Falls die Hardware-Uhr-Zeitskalenkonfiguration geandert 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 fehlschlagt. Siehe --update-drift weiter unten. --vl-read, --vl-clear Eine Echtzeituhren (RTC) konnen die Spannung der Stutzbatterie uberwachen und so dem Benutzer eine Moglichkeit geben zu beurteilen, wann die Batterie ersetzt werden sollte. Die Funktion --vl-read ermittelt die >>Voltage Low<<-Information und dekodiert das Ergebnis in eine menschenlesbare Form. Die Funktion --vl-clear setzt die >>Voltage Low<<-Information zuruck, was bei einigen RTC-Geraten nach dem Ersetzen der Batterie notwendig ist. Siehe die Datei include/uapi/linux/rtc.h des Kernels fur Details, welche Informationen zuruckgeliefert werden konnen. Beachten Sie, dass weder alle RTC-Gerate uber diese Uberwachungsmoglichkeit verfugen, noch alle Treiber notwendigerweise das Auslesen dieser Information unterstutzen. -h, --help zeigt einen Hilfetext an und beendet das Programm. -V, --version Display version and exit. OPTIONEN --adjfile=Dateiname setzt den vorgegebenen Dateipfad /etc/adjtime ausser Kraft. --date=Datumszeichenkette Diese Option muss zusammen mit den Funktionen --set oder --predict verwendet 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 gedruckt wird, abhangt. Sekundenbruchteile werden ohne Ruckmeldung abgeschnitten. Diese Option kann viele Zeit- und Datumsformate erkennen, aber die vorhergehenden Parameter sollten beachtet werden. --delay=Sekunden Diese Option erlaubt es, die intern verwendete Verzogerung beim Setzen der Uhrzeit zu andern. Die Vorgabe ist 0.5 (500 ms) fur rtc_cmos, fur andere RTC-Typen ist die Verzogerung 0. Falls der RTC-Typ nicht (aus Sysfs) bestimmt werden kann, dann ist die Vorgabe aufgrund der Ruckwartskompatibilitat auch 0.5. Die Standardverzogerung von 500 ms basiert auf der haufig verwendeten, 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 zusatzliche halbe Sekunde Verzogerung erfolgt, da die Hardwareuhr sich auf die folgende Sekunde genau 500 ms nach dem Setzen der neuen Zeit aktualisiert. Unglucklicherweise ist dieses Verhalten hardwareabhangig und in einigen Fallen wird eine andere Verzogerung benotigt. -D, --debug Verwenden Sie --verbose. Die Option --debug ist veraltet und kann in einer zukunftigen Veroffentlichung einer neuen Verwendung zugefuhrt oder entfernt werden. --directisa Diese Option ist auf ISA-kompatiblen Maschinen (einschliesslich x86 und x86_64) von Bedeutung. Auf anderen Maschinen hat sie keine Auswirkungen. Diese Option weist hwclock explizit an, E/A-Anweisungen fur den Zugriff auf die Hardware-Uhr vorzunehmen. Ohne diese Option versucht hwclock, die RTC-Geratdatei zu verwenden, wobei angenommen wird, dass diese mit dem Linux-RTC-Geratetreiber lauft. Seit v2.26 wird er nicht mehr automatisch directisa verwenden, wenn der RTC-Treiber nicht verfugbar ist. Dies fuhrte 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 systemabhangig (ULONG_MAX - 1). -f, --rtc=Dateiname Setzt den Vorgabe-RTC-Dateinamen von hwclock ausser Kraft. Anderenfalls wird der erste aus der folgenden Liste (in dieser Reihenfolge) verwendet: /dev/rtc0, /dev/rtc, /dev/misc/rtc. Fur 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 gewahlt wurde. Die Optionen --localtime und --utc ubergeben 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: Anderungen durch Sommerzeit-/Winterzeit-Wechsel konnen 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 mussen entweder --utc oder --localtime angegeben werden. --test andert tatsachlich 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 ungultige Berechnungen vermieden. Je langer die Periode, desto praziser wird der sich ergebende Abweichungsfaktor sein. Diese Option wurde in v2.26 hinzugefugt, da typischerweise auf Systemen beim Herunterfahren hwclock --systohc aufgerufen wird. Mit dem alten Verhalten wurde dabei automatisch der Abweichungsfaktor (neu) berechnet werden, wodurch mehrere Probleme entstanden: o Wird NTP mit einem >>11-Minuten-Modus<<-Kernel verwendet, wurde der Abweichungsfaktor auf fast Null verfremdet. o Es wurde nicht die Verwendung von >>kalter<<-Abweichungskorrektur erlauben. Bei den meisten Konfigurationen fuhrt die >>kalte<< Abweichungskorrektur zu besseren Ergebnissen. Kalt bedeutet, wenn die Maschine ausgeschaltet ist, was eine wesentliche Auswirkung auf den Abweichungsfaktor haben kann. o (Neu-)Berechnung des Abweichungsfaktors bei jedem Herunterfahren fuhrt zu suboptimalen Ergebnissen. Fuhren beispielsweise kurzzeitige Bedingungen dazu, dass die Maschine ungewohnlich heiss wird, ware die Abweichungsfaktorberechnung ausserhalb des Gultigkeitsbereichs. o Signifikant erhohte System-Runterfahrzeiten (bei v2.31 wird die RTC nicht gelesen, wenn --update-drift nicht verwendet wird). Die Berechnung des Abweichungsfaktors durch hwclock ist ein guter Start, aber fur optimale Ergebnisse wird wahrscheinlich die Datei /etc/adjtime direkt bearbeitet werden mussen. Bei den meisten Konfigurationen braucht die Abweichung nicht mehr verandert zu werden, sobald der optimale Abweichungsfaktor erstellt wurde. Daher wurde das alte Verhalten, die Abweichung automatisch (neu) zu berechnen, geandert und benotigt nun dafur eine Option. Lesen Sie die Diskussion weiter unten unter Die Adjust-Funktion. Diese Option benotigt die Hardwareuhr vor ihrem Setzen. Falls sie nicht gelesen werden kann, wird diese Option zum Fehlschlag der Setzen-Funktion fuhren. Dies kann beispielsweise passieren, falls die Hardwareuhr durch einen Stromausfall beschadigt ist. In diesem Fall muss die Uhr zuerst ohne diese Option gesetzt werden. Abgesehen davon, dass sie nicht funktioniert, ware der daraus resultierende Abweichungsfaktor sowieso ungultig. -v, --verbose zeigt mehr Details uber die internen Vorgange von hwclock an. ANMERKUNGEN Uhren in einem Linux-System Es gibt zwei Arten von Datum-Zeit-Uhren: Die Hardware-Uhr: Diese Uhr ist ein unabhangiges Hardware-Gerat, mit seinem eigenen Energiebereich (Batterie, Kondensatoren, usw.), das lauft, 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 Signalubergange der Ein-Sekunden-Impulse erkennen, so dass die Uhr uber virtuell unendliche Prazision verfugt. Diese Uhr wird allgemein die Hardware-Uhr, die Echtzeituhr, die RTC, die BIOS-Uhr oder die CMOS-Uhr genannt. Der Begriff Hardware-Uhr wurde fur hwclock gewahlt. Der Linux-Kernel bezeichnet sie auch als bestandige Uhr. Einige Nicht-ISA-Systeme haben ein paar Echtzeituhren, wobei nur eine davon ihre eigene Energieversorgung hat. Ein sehr energiesparender externer I^2C- oder SPI-Uhrchip konnte mit einer Stutzbatterie als Hardware-Uhr fungieren, um eine funktionellere integrierte Echtzeituhr zu initialisieren, die fur 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 lauft. Die Systemzeit wird als die Anzahl der Sekunden seit dem 1. Januar 1970 um 00:00:00 Uhr Weltzeit ausgedruckt, oder anders formuliert, die Anzahl der seit 1969 UTC vergangenen Sekunden. Die Systemzeit ist dennoch keine Ganzzahl. Sie hat virtuell unbegrenzte Prazision. 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 lauft, so dass die Systemzeit beim Systemstart daraus initialisiert werden kann. Beachten Sie, dass in DOS, wofur der ISA-Standard entworfen wurde, die Hardware-Uhr die einzig verfugbare Echtzeituhr ist. Es ist wichtig, dass die Zahlung der Systemzeit nicht unterbrochen wird, zum Beispiel wenn Sie mit dem Befehl date(1) die Systemzeit setzen, wahrend das System lauft. Sie konnen dennoch im laufenden Betrieb mit der Hardware-Uhr tun, was Sie wollen, und beim nachsten Linux-Start wird die Zeit der Hardware-Uhr entsprechend angepasst. Hinweis: Derzeit ist dies auf den meisten Systemen nicht moglich, da beim Herunterfahren hwclock --systohc aufgerufen wird. Die Zeitzone des Linux-Kernels wird durch hwclock gesetzt. Aber lassen Sie sich nicht in die Irre fuhren - beinahe niemand interessiert sich dafur, was der Kernel meint, in welcher Zeitzone er sich befindet. Stattdessen mussen Programme, fur die die Zeitzone wichtig ist (um Ihnen beispielsweise die lokale Zeit anzuzeigen), fast immer einen etwas traditionelleren Weg wahlen, um die Zeitzone zu ermitteln: Sie benutzen die TZ-Umgebungsvariable oder die Datei /etc/localtime, wie in der Handbuchseite zu tzset(3) erklart. Jedoch nutzen einige Programme und Teile des Linux-Kernels dessen Zeitzonenwert, zum Beispiel Dateisysteme. Ein Beispiel hierfur 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) gegenuber der Weltzeit zuruckbleibt, 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-Gerats. 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 unterstutzen. Damit konnte die Notwendigkeit entstehen, das Vorgabe-RTC-Gerat mit der Option --rtc ausser Kraft zu setzen. Allerdings ist diese Methode nicht immer verfugbar, da altere Systeme uber keinen RTC-Treiber verfugen. Auf diesen Systemen hangt die Art des Zugriffs auf die Hardware-Uhr von der Art der Systemhardware ab. Auf einem ISA-kompatiblen System kann hwclock direkt uber 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 dafur bestimmt sind, direkte E/A-Vorgange auszufuhren und Interrupts zu deaktivieren. hwclock bietet dies zum Testen, Fehlersuchen und da es auf ISA-kompatiblen Systemen, die uber keinen funktionierenden RTC-Geratetreiber verfugen, die einzige verfugbare Methode sein konnte. Die Adjust-Funktion Die Hardware-Uhr ist ublicherweise nicht sehr genau. Jedoch lasst 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 konnen Sie die Systemabweichung der Hardware-Uhr korrigieren. Es funktioniert folgendermassen: 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 tatsachliche aktuelle Zeit zu stellen. hwclock legt die adjtime-Datei an und zeichnet darin die Zeit als jene der letzten Kalibrierung der Uhr auf. Funf Tage spater geht die Uhr 10 Sekunden vor, und Sie rufen hwclock --set --update-drift auf, um die Uhr 10 Sekunden zuruckzustellen. 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 spater 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 spater 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 vollstandig 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 unterlasst --adjust Korrekturen von weniger als einer Sekunde. Wenn Sie zu einem spateren Zeitpunkt erneut die Uhr stellen wollen, wird die aufgesammelte Abweichung nun mehr als eine Sekunde betragen und --adjust fuhrt die Korrektur einschliesslich 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 andert weder die Hardware-Uhr noch die Adjtime-Datei. Dies konnte die Notwendigkeit von --adjust beseitigen, ausser etwas anderes auf dem System benotigt den Abgleich der Hardware-Uhr. Die Datei Adjtime Sie wurde wegen ihres fruheren ausschliesslichen Zwecks der Steuerung des Abgleichs so benannt und enthalt ausserdem Informationen, die hwclock fur spatere 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 Fliesskommazahl; 2) die sich ergebende Anzahl der Sekunden seit 1969 Weltzeit gemass der letzten Anpassung oder Kalibrierung als dezimale Ganzzahl; 3) Null (zwecks Kompatibilitat zu clock(8)) als dezimale Gleitkommazahl. Zeile 2: eine Zahl: die sich ergebende Anzahl der Sekunden seit 1969 Weltzeit gemass der letzten Kalibrierung. Dies ist Null, falls noch keine Kalibrierung ausgefuhrt wurde oder eine fruhere Kalibrierung fehlschlug (zum Beispiel wurde die Hardware-Uhr seit der Kalibrierung zwar gefunden, enthielt aber keine gultige 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 konnen diesen Wert stets mit den Befehlszeilenoptionen zu hwclock ausser Kraft setzen. Sie konnen eine adjtime-Datei, die fruher 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 verfugt uber einen Modus, in dem in Abstanden von 11 Minuten die Systemzeit in die Hardware-Uhr kopiert wird. Dieser Modus wird beim Kompilieren ausgewahlt, daher werden nicht alle Kernel uber diese Fahigkeit verfugen. Dieser Modus ist sinnvoll, wenn Sie etwas Fortschrittliches wie NTP verwenden, um die Systemuhr synchron zu halten. (NTP bezeichnet die Synchronisation der Systemzeit entweder uber einen Zeitserver im Netzwerk oder uber eine an Ihrem System angeschlossene Funkuhr, siehe RFC 1305.) Falls der Kernel mit der Option >>11-Minuten-Modus<< ubersetzt 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 aussen, 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 Ausfuhrung von allem, die die Systemuhr auf die althergekommene Art setzt, wie hwclock --hctosys, wieder ausgeschaltet werden. Falls der NTP-Daemon allerdings noch lauft, wird er den >>11-Minuten-Modus<< beim nachsten Synchronisieren der Systemuhr wieder einschalten. Falls Ihr System mit aktiviertem >>11-Minuten-Modus<< lauft, konnte 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 lauft, konnte er sie mit der falschen verfremden. Der Kernel verwendet standardmassig UTC. Der erste Benutzerraumbefehl, der die Systemuhr setzt, informiert den Kernel, welche Zeitskala die Hardware-Uhr verwendet. Dies passiert uber 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 Fahigkeit erfordert, dass bei Anderung der Hardware-Uhr-Zeitskalenkonfiguration ein Systemneustart zur Information des Kernels benotigt 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 fur 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 unnotig ist. Das year-of-century leistet gute Arbeit beim Ermitteln des aktuellen Jahrhunderts. Falls Sie einen echten Anwendungsfall fur das CMOS-Century-Byte haben, kontaktieren Sie den Betreuer von hwclock, eine Option konnte hier zweckdienlich sein. Beachten Sie, dass dieser Abschnitt nur relevant ist, wenn Sie die >>Direct ISA<<-Methode fur den Zugriff auf die Hardware-Uhr verwenden. ACPI bietet eine standardisierte Zugriffsmoglichkeit auf die Jahrhundertwerte an, sofern diese von der Hardware unterstutzt werden. DATUM-ZEIT-KONFIGURATION Zeit ohne externe Synchronisation erhalten Diese Diskussion basiert auf den folgenden Annahmen: o Es lauft nichts, das die Echtzeituhren andert, wie ein NTP-Daemon oder ein Cron-Job. o Die Systemzeitzone ist fur die korrekte lokale Zeit konfiguriert. Siehe unten unter POSIX kontra >>KORREKT<<. o Fruh wahrend des Systemstarts wird Folgendes in dieser Reihenfolge aufgerufen: adjtimex --tick Wert --frequency Wert hwclock --hctosys o Wahrend des Herunterfahrens wird folgendes aufgerufen: hwclock --systohc o Systeme ohne adjtimex konnen ntptime verwenden. Egal, ob eine Prazisionzeit mit einem NTP-Daemon verwaltet wird oder nicht, ist es sinnvoll, das System so konfigurieren, dass es allein eine vernunftig gute Datum-Uhrzeit halt. Im ersten Schritt dafur muss ein klares Verstandnis des Gesamtbildes erreicht werden. Es gibt zwei komplett getrennte Hardwaregerate, die alleine in ihrer eigenen Geschwindigkeit laufen und von der >>korrekten<< Zeit mit ihrer eigenen Rate abweichen. Die Methoden und Software fur die Abweichungskorrektur unterscheiden sich fur 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 Gerate zwischen beiden hin und her ubertragen. Wird versucht, nur bei einem von ihnen eine Abweichungskorrektur vorzunehmen, wird die Abweichung des anderen Gerats darubergelegt. Dieses Problem kann bei Konfiguration der Abweichung der Systemuhr vermieden werden, indem die Maschine nicht heruntergefahren wird. Dies und der Tatsache, dass die gesamte Prazision von hwclock (einschliesslich der Berechnung des Abweichungsfaktors) von der Korrektheit der Systemuhrrate abhangt, 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. (Fur 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 gekront sein, aber vorher ist grosser Aufwand und viel Frust involviert. Diese Automatisierung mag eine Verbesserung gegenuber keiner Konfiguration sein, aber optimale Ergebnisse zu erwarten, ware fehlerhaft. Eine bessere Wahl fur eine manuelle Konfiguration ware die Option --log von adjtimex. Es mag effizienter sein, einfach die Abweichung der Systemuhr mit sntp oder date -Ins und einem genauen Zeitstuck nachzuverfolgen und dann die Abweichung manuell zu berechnen. Nach dem Setzen der Tick- und Frequenzwerte fahren Sie mit dem Prufen und Verfeinern der Anpassungen fort, bis die Systemuhr eine gute Zeit halt. Siehe adjtimex(2) fur 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 Fallen am besten. Dies sollte sogar auf Maschinen zutreffen, die 24/7 laufen und deren normale Auszeit aus einem Systemneustart besteht. In diesen Fallen stellt der Abweichungsfaktor kaum einen Unterschied dar. Aber in den seltenen Fallen, in denen die Maschine fur eine langere Zeit ausgeschaltet wird, sollte die kalte Abweichung zu besseren Ergebnissen fuhren. 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 andern. 5 Starten Sie das System. 6 Verwenden Sie sofort hwclock, um die korrekte Zeit zu setzen, fugen 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 fur optimale Ergebnisse wird wahrscheinlich die Datei /etc/adjtime direkt bearbeitet werden mussen. Fahren Sie mit den Tests fort und verfeinern Sie den Abweichungsfaktor, bis die Hardware-Uhr beim Start exakt gestellt wird. Um dies zu uberprufen, stellen Sie zunachst sicher, dass die Systemzeit vor dem Herunterfahren korrekt gesetzt wurde und verwenden dann sntp oder date -Ins mit der gewunschten Prazision unmittelbar nach dem Start. LOKAL vs. UTC Wird die Hardware-Uhr in der lokalen Zeitskala betrieben, fuhrt dies zu inkonsistenten Sommerzeitergebnissen: o Falls Linux wahrend des Sommer-/Winterzeitwechsels lauft, wird die in die Hardware-Uhr geschriebene Zeit fur die Anderung angepasst. o Falls Linux NICHT wahrend des Sommer-/Winterzeitwechsels lauft, wird die von der Hardware-Uhr gelesene Zeit NICHT fur die Anderung angepasst werden. Die Hardware-Uhr auf einem ISA-kompatiblen System halt 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 lauft, an, dass es sich in der >>korrekten<< lokalen Zeit befindet und fuhrt keine Anpassungen fur die aus ihr gelesene Zeit durch. Linux fuhrt den Sommer-/Winterzeitwechsel nur korrekt durch, wenn die Hardware-Uhr in der UTC-Zeitskala lauft. Dies wird Systemadministratoren erleichtert, da hwclock die lokale Zeit fur seine Ausgabe und als Argument fur die Option --date verwendet. POSIX-Systeme sind wie Linux so entwickelt, dass die Systemuhr in der UTC-Zeitskala lauft. 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 berucksichtigen. Dies dient primar dem dualen Systemstart mit alteren Versionen von MS Windows. Seit Windows 7 soll der Registrierungsschlussel RealTimeIsUniversal korrekt funktionieren, so dass die Hardware-Uhr in UTC gehalten werden kann. POSIX kontra >>KORREKT<< Eine Diskussion der Datum/Zeit-Konfiguration ware allerdings unvollstandig, ohne Zeitzonen zu behandeln. Dies wird gut in tzset(3) abgedeckt. Ein Punkt, fur 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) enthalt Schaltsekunden, POSIX nicht. Um die >>korrekte<< Datenbank zu verwenden, muss die Systemuhr auf (UTC + Schaltsekunden) gesetzt sein, was zu (TAI - 10) aquivalent ist. Dies ermoglicht 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, einschliesslich UTC, umgewandelt, indem die >>korrekten<< Zeitzonendateien verwendet werden, die die Schaltsekunden abziehen. Hinweis: Diese Konfiguration wird als experimentell bezeichnet und hat bekanntermassen Probleme. Um ein System zur Verwendung einer bestimmten Datenbank zu konfigurieren, mussen 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 ublich, 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 Unglucklicherweise andern einige Linux-Distributionen dies in ihren Paketen wieder auf die alte Struktur zuruck. Daher besteht das Problem der Systemadministratoren, die in das >>korrekte<< Unterverzeichnis hineingreifen, weiter fort. Dies fuhrt dazu, dass die Systemzeitzone konfiguriert wird, Schaltsekunden zu beachten, wahrend die Zoneinfo-Datenbank weiterhin so konfiguriert ist, sie auszuschliessen. Wenn dann eine Anwendung wie die >>World Clock<< die Zeitzonendatei South_Pole benotigt oder ein E-Mail-MTA oder hwclock die UTC-Zeitzonen-Datei benotigen, holen sie sie von der Wurzel von /usr/share/zoneinfo, da das so von ihnen erwartet wird. Diese Dateien schliessen Schaltsekunden aus, aber die Systemuhr berucksichtigt 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 gemass 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 Ruckgabewerte wird zuruckgeliefert: EXIT_SUCCESS ('0' auf POSIX-Systemen) Erfolgreiche Programmausfuhrung. EXIT_FAILURE ('1' auf POSIX-Systemen) Die Aktion ist fehlgeschlagen oder die Befehlssyntax war ungultig. UMGEBUNGSVARIABLEN TZ Falls diese Variable gesetzt ist, hat ihr Wert gegenuber der im System konfigurierten Zeitzone Vorrang. TZDIR Falls diese Variable gesetzt ist, hat ihr Wert gegenuber dem im System konfigurierten Zeitzonendatenbankverzeichnispfad Vorrang. DATEIEN /etc/adjtime Die Konfiguration und die Zustandsdateien fur hwclock. Siehe auch adjtime_config(5). /etc/localtime Die Systemzeitzonendatei /usr/share/zoneinfo/ Das System-Zeitzonen-Datenbankverzeichnis Geratedateien, die hwclock fur 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 , September 1996, basierend auf dem Programm clock(8) von Charles Hedrick, Rob Hooft und Harald Koenig. Im Quellcode finden Sie die vollstandige Geschichte einschliesslich der Danksagungen. FEHLER MELDEN For bug reports, use the issue tracker . VERFUGBARKEIT Der Befehl hwclock ist Teil des Pakets util-linux, welches aus dem Linux-Kernel-Archiv heruntergeladen werden kann. util-linux 2.41 2025-03-29 HWCLOCK(8)