HWCLOCK(8)

NAMN
hwclock - verktyg för tidsklockor

SYNOPSIS

hwclock [function] [option...]

BESKRIVNING

hwclock är ett administrationsverktyg för tidsklockorna. Det kan: visa maskinvaruklockans tid; ställa in maskinvaruklockan till en angiven tid; ställa in maskinvaruklockan från systemklockan; ställa in systemklockan från maskinvaruklockan; kompensera för drift av maskinvaruklockan; korrigera systemklockans tidsskala; ställa in kärnans tidszon, NTP-tidsskala och epok (endast Alpha); och förutsäga framtida värden för maskinvaruklockan baserat på dess drifthastighet.

Sedan v2.26 har viktiga ändringar gjorts i funktionen --hctosys och flaggan --directisa, och en ny flagga --update-drift har lagts till. Se deras respektive beskrivningar nedan.

FUNKTIONER

Följande funktioner är ömsesidigt uteslutande, endast en kan anges åt gången. Om ingen anges är standardvärdet --show.

-a, --adjust
    Lägg till eller dra ifrån tid från hårdvaruklockan för att ta hänsyn till systematisk drift sedan klockan senast ställdes in eller justerades. Se diskussionen nedan under Justeringsfunktionen.

--getepoch; --setepoch
    Dessa funktioner är endast avsedda för Alpha-maskiner och är endast tillgängliga via RTC-drivrutinen i Linux-kärnan.

    De används för att läsa och ställa in kärnans epokvärde för maskinvaruklockan. Epoch är det antal år in i AD som ett nollårsvärde i maskinvaruklockan hänvisar till. Om maskinens BIOS t.ex. ställer in årsräknaren i maskinvaruklockan så att den innehåller antalet hela år sedan 1952, måste kärnans epokvärde för maskinvaruklockan vara 1952.

    Funktionen --setepoch kräver att man använder flaggan --epoch för att ange årtalet. Till exempel:

    hwclock --setepoch --epoch=1952

    RTC-drivrutinen försöker gissa sig till rätt epokvärde, så det kanske inte är nödvändigt att ställa in det.

    Detta epokvärde används när hwclock läser av eller ställer in maskinvaruklockan på en Alpha-maskin. För ISA-maskiner använder kärnan den fasta epoken för maskinvaruklockan 1900.

--param-get=parameter; --param-set=parameter=värde
    Läs och ställ in RTC:s parameter. Detta är användbart för att t.ex. hämta RTC:ns funktion eller ställa in RTC:ns backup-omkopplingsläge.

    parameter är antingen ett numeriskt RTC-parametervärde (se Kernels include/uapi/linux/rtc.h) eller ett alias. Se --help för en lista över giltiga alias. parameter och värde, om de föregås av 0x, tolkas som hexadecimala värden, annars som decimala värden.

--param-index number
    Select an instance of the same RTC parameter with it’s index number. The default value for number is 0.

--predict
    Förutse vad maskinvaruklockan kommer att visa i framtiden baserat på den tid som anges med flaggan --date och informationen i /etc/adjtime. Detta är användbart, till exempel för att ta hänsyn till drift när du ställer in en väckning (även kallat larm) av maskinvaruklockan. Se rtcwake(8).

    Använd inte den här funktionen om maskinvaruklockan ändras av något annat än det aktuella operativsystemets hwclock-kommando, t.ex. i "11-minutersläge" eller om du dubbelstartar ett annat operativsystem.

-r, --show; --get
    Läs av maskinvaruklockan och skriv ut dess tid till standardutdata i formatet ISO 8601. Tiden som visas är alltid i lokal tid, även om du håller maskinvaruklockan i UTC. Se flaggan --localtime.

    Showing the Hardware Clock time är standardinställningen när ingen funktion anges.

    Funktionen --get tillämpar också driftkorrigering på den avlästa tiden, baserat på informationen i /etc/adjtime. Använd inte den här funktionen om maskinvaruklockan modifieras av något annat än det aktuella operativsystemets hwclock-kommando, t.ex. i "11-minutersläge" eller genom att dubbelstarta ett annat operativsystem.

-s, --hctosys
    Ställ in systemklockan från maskinvaruklockan. Den tid som avläses från maskinvaruklockan kompenseras för systematisk drift innan den används för att ställa in systemklockan. Se diskussionen nedan under Justeringsfunktionen.

    Systemklockan måste ställas in på UTC-tidsskalan för att datum- och tidstillämpningar ska fungera korrekt tillsammans med den tidszon som har konfigurerats för systemet. Om maskinvaruklockan hålls i lokal tid måste den tid som läses från den flyttas till UTC-tidsskalan innan den används för att ställa in systemklockan. Funktionen --hctosys gör detta baserat på informationen i filen /etc/adjtime eller kommandoradsargumenten --localtime och --utc. Observera: ingen justering för sommartid görs. Se diskussionen nedan under LOCAL vs UTC.

    Kärnan håller också ett tidszonsvärde, funktionen --hctosys ställer in det till den tidszon som konfigurerats för systemet. Systemets tidszon konfigureras av miljövariabeln TZ eller filen /etc/localtime, som tzset(3) skulle tolka dem. Det föråldrade fältet tz_dsttime i kärnans tidszonsvärde sätts till noll. (För detaljer om vad det här fältet brukade betyda, se settimeofday(2)

    När funktionen --hctosys används i ett startskript och blir den första funktionen som anropar settimeofday(2) från start, kommer den att ställa in NTP:s tidsskala '11 minute mode' via kärnvariabeln persistent_klocka_is_local. Om konfigurationen av hårdvaruklockans tidsskala ändras krävs en omstart för att informera kärnan. Se diskussionen nedan under Automatisk synkronisering av maskinvaruklockan via kärnan.

    Det här är en bra funktion att använda i ett av systemets startskript innan filsystemen monteras för läsning/skrivning.

    Den här funktionen ska aldrig användas på ett system som körs. Att hoppa över systemtiden kommer att orsaka problem, t.ex. korrupta tidsstämplar i filsystemet. Om något har ändrat hårdvaruklockan, som NTP:s "11-minutersläge", kommer --hctosys att ställa in tiden felaktigt genom att inkludera driftkompensation.

    Driftkompensering kan förhindras genom att driftfaktorn i /etc/adjtime sätts till noll. Denna inställning kommer att vara bestående så länge flaggan --update-drift inte används med --systohc vid avstängning (eller någon annanstans). Ett annat sätt att förhindra detta är att använda flaggan --noadjfile när du anropar funktionen --hctosys. En tredje metod är att radera filen /etc/adjtime. Hwclock kommer då som standard att använda UTC-tidsskalan för maskinvaruklockan. Om maskinvaruklockan tickar lokal tid måste den definieras i filen. Detta kan göras genom att anropa hwclock --localtime --adjust; när filen inte finns kommer detta kommando inte att justera klockan, men det kommer att skapa filen med lokal tid konfigurerad och en driftfaktor på noll.

    En situation där det kan vara önskvärt att inhibera hwclock:s driftkorrigering är när man dubbelstartar flera operativsystem. Om ett annat operativsystem ändrar hårdvaruklockans värde medan den här Linux-instansen är stoppad, kommer den driftkorrigering som tillämpas att vara felaktig när den här instansen startas igen.

    För att hwclock:s driftkorrigering ska fungera korrekt är det absolut nödvändigt att inget ändrar hårdvaruklockan när dess Linux-instans inte körs.

--set
    Ställ in hårdvaruklockan på den tid som anges av flaggan --date och uppdatera tidsstämplarna i /etc/adjtime. Med flaggan --update-drift (om)beräknar du även driftfaktorn. Prova utan flaggan om --set misslyckas. Se --update-drift nedan.

--systz
    Detta är en flagga till funktionen --hctosys som inte läser av hårdvaruklockan eller ställer in systemklockan; följaktligen sker ingen driftkorrigering. Den är avsedd att användas i ett uppstartsskript på system med kärnor över version 2.6 där du vet att systemklockan har ställts in från maskinvaruklockan av kärnan under uppstarten.

    Den gör följande saker som beskrivs ovan i funktionen --hctosys:

        • Korrigerar systemklockans tidsskala till UTC efter behov. Men istället för att göra detta genom att ställa in systemklockan, informerar hwclock helt enkelt kärnan som hanterar ändringen.

        • Ställer in kärnans NTP-tidsskala för "11-minutersläge".

        • Ställer in kernelns tidszon.

    De två första är endast tillgängliga vid det första anropet av settimeofday(2) efter uppstart. Följaktligen är denna flagga bara meningsfullt när det används i ett startskript. Om konfigurationen av tidsskalan för hårdvaruklockor ändras krävs en omstart för att informera kärnan.

-w, --systohc
    Ställ in hårdvaruklockan från systemklockan och uppdatera tidsstämplarna i /etc/adjtime. Med flaggan --update-drift (om)beräknar du även driftfaktorn. Prova utan flaggan om --systohc misslyckas. Se --update-drift nedan.

--vl-read, --vl-clear
    Vissa RTC-enheter kan övervaka spänningen i reservbatteriet och på så sätt ge användaren möjlighet att veta att batteriet bör bytas ut. Funktionen --vl-read hämtar Voltage Low-informationen och avkodar resultatet till läsbar form för människor. Funktionen --vl-clear återställer Voltage Low-informationen, vilket är nödvändigt för vissa RTC-enheter efter ett batteribyte.

    Se kärnans include/uapi/linux/rtc.h för mer information om vilka delar av informationen som kan returneras. Observera att inte alla RTC-enheter har den här övervakningsmöjligheten och att alla drivrutiner inte nödvändigtvis stöder läsning av informationen.

-h, --help
    Visa hjälptext och avsluta.

-V, --version
    Visa version och avsluta.

FLAGGOR

--adjfile=filename
    Åsidosätt standardfilsökvägen /etc/adjtime.

--date=date_sträng
    Denna flagga måste användas tillsammans med funktionerna --set eller --predict, annars ignoreras det.

    hwclock --set --date='16:45'

    hwclock --predict --date='2525-08-14 07:11:05'

    Argumentet måste vara i lokal tid, även om du håller din hårdvaruklocka i UTC. Se flaggan --localtime. Därför bör argumentet inte innehålla någon tidszonsinformation. Det bör inte heller vara en relativ tid som "+5 minuter", eftersom hwclock:s precision beror på korrelationen mellan argumentets värde och när enter-tangenten trycks in. Bråkdelar av sekunder faller bort. Den här flaggan kan förstå många tids- och datumformat, men de föregående parametrarna bör följas.

--delay=seconds
    This option overrides the default delay used when setting the clock time. The default is 0.5 (500 ms) for rtc_cmos; for other RTC types the delay is 0. If the RTC type cannot be determined (from sysfs), then the delay defaults also to 0.5 to be backwardly compatible.

    The 500 ms default is based on the commonly used MC146818A-compatible (x86) hardware clock. This Hardware Clock can only be set to an integer time plus one half second. The integer time is required because there is no interface to get or set a fractional second. The additional half second is because the Hardware Clock updates to the following second precisely 500 ms after setting the new time. Unfortunately, this behavior is hardware specific and in some cases a different delay is required.

-D, --debug
    Använd --verbose. Flaggan --debug har utgått och kan komma att återanvändas eller tas bort i en framtida version.

--directisa
    Denna flagga är meningsfull för ISA-kompatibla maskiner i x86- och x86_64-familjen. För andra maskiner har det ingen effekt. Den här flaggan talar om för hwclock att använda explicita I/O-instruktioner för att komma åt maskinvaruklockan. Utan den här flaggan kommer hwclock att använda enhetsfilen rtc, som antas drivas av Linux RTC-enhetsdrivrutin. Från och med v2.26 används inte längre automatiskt directisa när rtc-drivrutinen inte är tillgänglig; detta orsakade ett osäkert tillstånd som kunde göra det möjligt för två processer att komma åt maskinvaruklockan samtidigt. Direkt hårdvaruåtkomst från userspace bör endast användas för testning, felsökning och som en sista utväg när alla andra metoder misslyckas. Se flaggan --rtc.

--epoch=year
    Denna flagga krävs när du använder funktionen --setepoch. Det minsta year-värdet är 1900. Maxvärdet är systemberoende (ULONG_MAX - 1).

-f, --rtc=filename
    Override hwclock's default rtc device file name. Otherwise it will use the first one found in this order: /dev/rtc, /dev/rtc0, /dev/misc/rtc. For IA-64: /dev/efirtc /dev/misc/efirtc

-l, --localtime; -u, --utc
    Anger vilken tidsskala hårdvaruklockan är inställd på.

    Hårdvaruklockan kan konfigureras att använda antingen UTC eller den lokala tidsskalan, men inget i själva klockan säger vilket alternativ som används. Flaggorna --localtime eller --utc ger denna information till kommandot hwclock. Om du anger fel flagga (eller inte anger någon av flaggorna och använder en felaktig standard) blir både inställning och avläsning av hårdvaruklockan felaktig.

    Om du varken anger --utc eller --localtime används den tid som senast angavs med en set-funktion (--set, --systohc eller --adjust) och som finns registrerad i /etc/adjtime. Om adjtime-filen inte finns är standard UTC.

    Observera: ändringar av sommartid kan vara inkonsekventa när maskinvaruklockan hålls i lokal tid. Se diskussionen nedan under LOKALTID vs UTC.

--noadjfile
    Inaktivera de funktioner som tillhandahålls av /etc/adjtime. hwclock kommer inte att läsa eller skriva till den filen med den här flaggan. Antingen --utc eller --localtime måste anges när denna flagga används.

--test
    Ändra faktiskt ingenting i systemet, dvs. inte klockorna eller /etc/adjtime (--verbose är implicit med denna flagga).

--update-drift
    Uppdatera hårdvaruklockans driftfaktor i /etc/adjtime. Den kan endast användas med --set eller --systohc.

    Det måste gå minst fyra timmar mellan inställningarna. Detta för att undvika ogiltiga beräkningar. Ju längre perioden är, desto mer exakt blir den resulterande driftfaktorn.

    Denna flagga lades till i v2.26, eftersom det är vanligt att system anropar hwclock --systohc vid avstängning; med det gamla beteendet skulle detta automatiskt (om)beräkna driftfaktorn, vilket orsakade flera problem:

        • Vid användning av NTP med en "11 minuters mode"-kärna skulle driftfaktorn bli nära noll.

        • Det skulle inte tillåta användning av korrigering av "kall" drift. Med de flesta konfigurationer ger användning av "kall" drift goda resultat. Kall innebär att maskinen är avstängd, vilket kan ha en betydande inverkan på driftfaktorn.

        • att (om)beräkna driftfaktorn vid varje avstängning ger suboptimala resultat. Om t.ex. tillfälliga förhållanden gör att maskinen blir onormalt varm skulle beräkningen av driftfaktorn hamna utanför intervallet.

        • Betydligt längre avstängningstid för systemet (från och med v2.31 när --update-drift inte används läses inte RTC).

    Having hwclock calculate the drift factor is a good starting point, but for optimal results it will likely need to be adjusted by directly editing the /etc/adjtime file. For most configurations once a machine’s optimal drift factor is crafted it should not need to be changed. Therefore, the old behavior to automatically (re)calculate drift was changed and now requires this option to be used. See the discussion below, under The Adjust Function.
    This option requires reading the Hardware Clock before setting it. If it cannot be read, then this option will cause the set functions to fail. This can happen, for example, if the Hardware Clock is corrupted by a power failure. In that case, the clock must first be set without this option. Despite it not working, the resulting drift correction factor would be invalid anyway.

-v, --verbose
    Visa mer detaljer om vad hwclock gör internt.

ANTECKNINGAR

  Klockor i ett Linux-system

Det finns två typer av datum- och tidsklockor:

Hårdvaruklockan: Denna klocka är en oberoende hårdvaruenhet med egen strömförsörjning (batteri, kondensator etc.) som fungerar när maskinen är avstängd eller till och med urkopplad.

På ett ISA-kompatibelt system är denna klocka specificerad som en del av ISA-standarden. Ett styrprogram kan bara läsa av eller ställa in den här klockan på en hel sekund, men det kan också upptäcka kanterna på klockans 1 sekunds tick, så klockan har faktiskt praktiskt taget oändlig precision.

Denna klocka kallas vanligen hårdvaruklockan, realtidsklockan, RTC, BIOS-klockan och CMOS-klockan. Hårdvaruklocka, i sin kapitaliserade form, myntades för användning av hwclock. Linuxkärnan hänvisar också till den som den permanenta klockan.

Vissa system som inte är ISA-anslutna har flera realtidsklockor, men bara en av dem har en egen spänningsdomän. Ett externt I2C- eller SPI-klockchip med mycket låg effekt kan användas med ett reservbatteri som hårdvaruklocka för att initiera en mer funktionell integrerad realtidsklocka som används för de flesta andra ändamål.

Systemklockan: Denna klocka är en del av Linuxkärnan och drivs av ett timeravbrott. (På en ISA-maskin är timeravbrottet en del av ISA-standarden.) Den har betydelse endast när Linux körs på maskinen. Systemtiden är antalet sekunder sedan 00:00:00 den 1 januari 1970 UTC (eller mer kortfattat, antalet sekunder sedan 1969 UTC). Systemtiden är dock inte ett heltal. Den har praktiskt taget oändlig precision.

Systemtiden är den tid som är viktig. Hårdvaruklockans grundläggande syfte är att hålla tiden när Linux inte körs så att systemklockan kan initialiseras från den vid uppstart. Observera att i DOS, som ISA utformades för, är maskinvaruklockan den enda realtidsklockan.

Det är viktigt att systemtiden inte har några diskontinuiteter, vilket skulle hända om du använde programmet date(1) för att ställa in den medan systemet körs. Du kan dock göra vad du vill med maskinvaruklockan medan systemet körs, och nästa gång Linux startar kommer det att göra det med den justerade tiden från maskinvaruklockan. Observera: För närvarande är detta inte möjligt på de flesta system eftersom hwclock --systohc anropas vid avstängning.

Linuxkärnans tidszon ställs in av hwclock. Men låt dig inte vilseledas - nästan ingen bryr sig om vilken tidszon kärnan tror att den befinner sig i. Istället använder program som bryr sig om tidszonen (kanske för att de vill visa en lokal tid för dig) nästan alltid en mer traditionell metod för att bestämma tidszonen: De använder miljövariabeln TZ eller filen /etc/localtime, vilket förklaras i man-sidan för tzset(3). Vissa program och delar av Linux-kärnan, t.ex. filsystem, använder dock kärnans tidszonsvärde. Ett exempel är filsystemet vfat. Om kärnans tidszonsvärde är fel kommer filsystemet vfat att rapportera och sätta fel tidsstämplar på filer. Ett annat exempel är kärnans NTP '11 minuters läge'. Om kärnans tidszonsvärde och/eller variabeln persistent_klocka_is_local är fel, kommer hårdvaruklockan att ställas in felaktigt av "11-minutersläget". Se diskussionen nedan, under Automatisk synkronisering av maskinvaruklockan av kärnan.

hwclock ställer in kärnans tidszon till det värde som anges av TZ eller /etc/localtime med funktionerna --hctosys eller --systz.

Kärnans tidszonsvärde består egentligen av två delar: 1) ett fält tz_minuteswest som anger hur många minuter lokal tid (ej justerad för sommartid) ligger efter UTC, och 2) ett fält tz_dsttime som anger vilken typ av sommartidskonvention som gäller på den aktuella platsen för närvarande. Det andra fältet används inte under Linux och är alltid noll. Se även settimeofday(2).

  Metoder för åtkomst till hårdvaruklocka

hwclock använder många olika sätt att hämta och ställa in värden för maskinvaruklockan. Det mest normala sättet är att göra I/O till specialfilen rtc device, som förutsätts drivas av drivrutinen rtc device. Linux-system som använder rtc-ramverket med udev kan dessutom stödja flera maskinvaruklockor. Detta kan medföra ett behov av att åsidosätta standard rtc-enheten genom att ange en med flaggan --rtc.

Denna metod är dock inte alltid tillgänglig eftersom äldre system inte har någon rtc-drivrutin. På dessa system beror metoden för att komma åt hårdvaruklockan på systemets maskinvara.

På ett ISA-kompatibelt system kan hwclock få direkt tillgång till de register i "CMOS-minnet" som utgör klockan genom att göra I/O till portarna 0x70 och 0x71. Den gör detta med faktiska I/O-instruktioner och kan därför bara göra det om den körs med superuser effective userid. Den här metoden kan användas genom att ange flaggan --directisa.

Det här är en riktigt dålig metod för att komma åt klockan, av alla de skäl som gör att program i användarutrymmet i allmänhet inte ska göra direkta I/O och inaktivera avbrott. hwclock tillhandahåller den för testning, felsökning och för att det kan vara den enda tillgängliga metoden på ISA-system som inte har en fungerande rtc-enhetsdrivrutin.

  Justeringsfunktionen

Hårdvaruklockan är vanligtvis inte särskilt exakt. En stor del av dess felaktighet är dock helt förutsägbar - den vinner eller förlorar samma tid varje dag. Detta kallas systematisk drift. med hwclock:s --adjust-funktion kan du korrigera den systematiska driften i maskinvaruklockan.

Det fungerar på följande sätt: hwclock har en fil, /etc/adjtime, som innehåller viss historisk information. Denna fil kallas adjtime-filen.

Anta att du börjar med att inte ha någon adjtime-fil. Du ger kommandot hwclock --set för att ställa in maskinvaruklockan till den verkliga aktuella tiden. hwclock skapar adjtime-filen och registrerar i den den aktuella tiden när klockan senast kalibrerades. Fem dagar senare har klockan gått fram 10 sekunder, så du ger kommandot hwclock --set --update-drift för att ställa tillbaka den 10 sekunder. hwclock uppdaterar adjtime-filen så att den visar den aktuella tiden som den senaste gången klockan kalibrerades, och registrerar 2 sekunder per dag som den systematiska drifthastigheten. 24 timmar går, och sedan ger du kommandot hwclock --adjust. hwclock konsulterar adjtime-filen och ser att klockan vinner 2 sekunder per dag när den lämnas i fred och att den har lämnats i fred i exakt en dag. Så den subtraherar 2 sekunder från maskinvaruklockan. Sedan registreras den aktuella tiden som den senaste gången klockan justerades. Ytterligare 24 timmar går och du utfärdar en ny hwclock --adjust. hwclock gör samma sak: subtraherar 2 sekunder och uppdaterar adjtime-filen med den aktuella tiden då klockan senast justerades.

När du använder flaggan --update-drift med --set eller --systohc, beräknas den systematiska driftfaktorn (på nytt) genom att jämföra den helt driftkorrigerade aktuella hårdvaruklockans tid med den nya inställda tiden, från vilken den 24 timmars driftfaktorn härleds baserat på den senast kalibrerade tidsstämpeln från adjtime-filen. Denna uppdaterade driftfaktor sparas sedan i /etc/adjtime.

En liten mängd fel smyger sig in när hårdvaruklockan ställs in, så --adjust avstår från att göra någon justering som är mindre än 1 sekund. Senare, när du begär en justering igen, kommer den ackumulerade avvikelsen att vara mer än 1 sekund och --adjust kommer att göra justeringen inklusive eventuella bråkdelar.

hwclock --hctosys använder också data från adjtime-filen för att kompensera det värde som läses från maskinvaruklockan innan det används för att ställa in systemklockan. Den har inte samma begränsning på 1 sekund som --adjust, och korrigerar driftvärden på under en sekund omedelbart. Den ändrar inte hårdvaruklockans tid och inte heller adjtime-filen. Detta kan eliminera behovet av att använda --adjust, såvida inte något annat i systemet kräver att maskinvaruklockan kompenseras.

  Adjtime-filen

Den har fått sitt namn på grund av sitt historiska syfte att endast kontrollera justeringar, men den innehåller faktiskt annan information som används av hwclock från ett anrop till nästa.

Formatet på filen adjtime är i ASCII:

Rad 1: Tre tal, åtskilda av blanksteg: 1) den systematiska drifthastigheten i sekunder per dag, decimal med flyttal; 2) det resulterande antalet sekunder sedan 1969 UTC för senaste justering eller kalibrering, heltal med decimal; 3) noll (för kompatibilitet med clock(8)) som decimal med flyttal.

Linje 2: Ett tal: det resulterande antalet sekunder sedan 1969 UTC för den senaste kalibreringen. Noll om ingen kalibrering har gjorts ännu eller om det är känt att någon tidigare kalibrering är ogiltig (t.ex. för att hårdvaruklockan efter den kalibreringen inte har visat sig innehålla en giltig tid). Detta är ett heltal med decimaltal.

Rad 3: "UTC" eller "LOKAL". Anger om maskinvaruklockan är inställd på Coordinated Universal Time eller lokal tid. Du kan alltid åsidosätta detta värde med flaggor på kommandoraden hwclock.

Du kan använda en adjtime-fil som tidigare har använts med programmet clock(8) med hwclock.

  Automatisk synkronisering av hårdvaruklockan genom kärnan

Du bör känna till ett annat sätt som maskinvaruklockan hålls synkroniserad på i vissa system. Linuxkärnan har ett läge där den kopierar systemtiden till maskinvaruklockan var 11:e minut. Det här läget är en kompileringsflagga, så det är inte alla kärnor som har den här möjligheten. Det här är ett bra läge att använda när du använder något sofistikerat som NTP för att hålla systemklockan synkroniserad. (NTP är ett sätt att hålla systemtiden synkroniserad antingen med en tidsserver någonstans i nätverket eller med en radioklocka som är ansluten till systemet. Se RFC 1305.)

Om kärnan är kompilerad med flaggan '11 minute mode' kommer det att vara aktivt när kärnans klockdisciplin är i ett synkroniserat tillstånd. I detta läge är bit 6 (den bit som sätts i masken 0x0040) i kärnans time_status-variabel osatt. Detta värde visas som "status"-raden i kommandona adjtimex --print eller ntptime.

Det krävs en yttre påverkan, som NTP-daemon, för att sätta kärnans klockdisciplin i ett synkroniserat tillstånd och därmed aktivera "11-minutersläget". Det kan stängas av genom att köra något som ställer in systemklockan på det gamla sättet, inklusive hwclock --hctosys. Men om NTP-daemon fortfarande körs kommer den att slå på "11-minutersläget" igen nästa gång den synkroniserar systemklockan.

Om ditt system körs med "11-minutersläget" aktiverat kan det behöva använda antingen --hctosys eller --systz i ett startskript, speciellt om maskinvaruklockan är konfigurerad att använda den lokala tidsskalan. Om inte kärnan får information om vilken tidsskala maskinvaruklockan använder, kan den komma att använda fel tidsskala. Kärnan använder UTC som standard.

Det första kommandot i userspace för att ställa in systemklockan informerar kärnan om vilken tidsskala hårdvaruklockan använder. Detta sker via kärnvariabeln persistent_klocka_is_local. Om --hctosys eller --systz är det första kommandot kommer det att ställa in denna variabel enligt adjtime-filen eller lämpligt kommandoradsargument. Observera att när den här funktionen används och konfigurationen av tidsskalan för maskinvaruklockan ändras, krävs en omstart för att kärnan ska informeras.

hwclock --adjust bör inte användas med NTP "11 minuters läge".

  ISA hårdvaruklocka Century-värde

Det finns någon form av standard som definierar CMOS-minnesbyte 50 på en ISA-maskin som en indikator på vilket århundrade det är. hwclock använder eller ställer inte in den byten eftersom det finns vissa maskiner som inte definierar byten på det sättet, och det är egentligen inte nödvändigt ändå, eftersom årtalet gör ett bra jobb med att antyda vilket århundrade det är.

Om du har en bona fide-användning för en CMOS century byte, kontakta hwclock-underhållaren; en flagga kan vara lämpligt.

Observera att detta avsnitt endast är relevant när du använder "direkt ISA"-metoden för att komma åt maskinvaruklockan. ACPI tillhandahåller ett standardiserat sätt att komma åt century-värden, när de stöds av maskinvaran.

KONFIGURATION AV DATUM OCH TID

  Hålla tiden utan extern synkronisering

Denna diskussion baseras på följande förutsättningar:

    • Inget körs som ändrar datum- och tidsklockorna, t.ex. NTP-daemon eller ett cron-jobb."

    • Systemets tidszon är konfigurerad för korrekt lokal tid. Se nedan, under POSIX vs 'RIGHT'.

    • Tidigt under uppstarten anropas följande, i denna ordning: adjtimex --tick värde --frequency värde hwclock --hctosys

    • Under avstängningen anropas följande: hwclock --systohc

        • System utan adjtimex kan använda ntptime.

Oavsett om du använder NTP-daemon för att hålla exakt tid eller inte, är det vettigt att konfigurera systemet så att det håller en någorlunda bra datumtid på egen hand.

Det första steget för att åstadkomma detta är att ha en tydlig förståelse för helheten. Det är två helt separata hårdvaruenheter som körs i sin egen hastighet och som avviker från den "korrekta" tiden i sin egen takt. Metoderna och programvaran för driftkorrigering är olika för var och en av dem. De flesta system är dock konfigurerade för att utbyta värden mellan dessa två klockor vid start och avstängning. Nu överförs de enskilda enheternas fel i tidshållningen fram och tillbaka mellan varandra. Om du försöker konfigurera driftkorrigering för endast en av dem, kommer den andra enhetens drift att överlagras på den.

Detta problem kan undvikas vid konfigurering av driftkorrigering för systemklockan genom att helt enkelt inte stänga av maskinen. Detta, plus det faktum att all hwclock:s precision (inklusive beräkning av driftfaktorer) är beroende av att systemklockans takt är korrekt, innebär att konfigurationen av systemklockan bör göras först.

Systemklockans drift korrigeras med kommandot adjtimex(8) med flaggan --tick och --frequency. Dessa två fungerar tillsammans: tick är grovjusteringen och frekvensen är finjusteringen. (För system som inte har ett adjtimex-paket kan ntptime -f ppm användas istället)

Vissa Linux-distributioner försöker automatiskt beräkna systemklockans drift med adjtimex:s jämförelseoperation. Att försöka korrigera en driftande klocka genom att använda en annan driftande klocka som referens är som en hund som försöker fånga sin egen svans. Framgång kan ske så småningom, men stora ansträngningar och frustration kommer sannolikt att föregå det. Denna automatisering kan ge en förbättring jämfört med ingen konfiguration, men att förvänta sig optimala resultat skulle vara felaktigt. Ett bättre val för manuell konfiguration skulle vara adjtimex:s --log-flaggor.

Det kan vara mer effektivt att helt enkelt följa systemklockans drift med sntp eller date -Ins och ett precisionsur och sedan beräkna korrigeringen manuellt.

När du har ställt in värdena för tick och frekvens fortsätter du att testa och förfina justeringarna tills systemklockan håller rätt tid. Se adjtimex(2) för mer information och ett exempel som visar manuella driftberäkningar.

När systemklockan tickar jämnt kan du gå vidare till hårdvaruklockan.

Som regel fungerar kall drift bäst för de flesta användningsfall. Detta bör gälla även för 24/7-maskiner vars normala stilleståndstid består av en omstart. I det fallet gör värdet på driftfaktorn ingen större skillnad. Men i de sällsynta fall då maskinen är avstängd under en längre period bör kall drift ge bättre resultat.

Steg för att beräkna kölddrift:

1
    Se till att NTP-daemon inte startas vid uppstart.

2
    Tiden för Systemklockan måste vara korrekt vid avstängning!

3
    Stäng av systemet.

4
    Låt en längre period gå utan att ändra hårdvaruklockan.

5
    Starta systemet.

6
    Använd omedelbart hwclock för att ställa in rätt tid, och lägg till flaggan --update-drift.

Obs: Om steg 6 använder --systohc, måste systemklockan ställas in korrekt (steg 6a) precis innan detta görs.

Att låta hwclock beräkna driftfaktorn är en bra utgångspunkt, men för optimala resultat måste den sannolikt justeras genom att direkt redigera filen /etc/adjtime. Fortsätt att testa och förfina driftfaktorn tills maskinvaruklockan korrigeras korrekt vid uppstart. För att kontrollera detta ska du först se till att systemtiden är korrekt före avstängning och sedan använda sntp, eller date -Ins och ett precisionsur, omedelbart efter uppstart.

  LOCAL vs UTC

Att hålla hårdvaruklockan i en lokal tidsskala ger inkonsekventa resultat för sommartid:

    • Om Linux körs under en sommartidsändring kommer den tid som skrivs till maskinvaruklockan att justeras för ändringen.

    • Om Linux INTE körs under en sommartidsändring kommer den tid som avläses från maskinvaruklockan INTE att justeras för ändringen.

Hårdvaruklockan på ett ISA-kompatibelt system håller bara datum och tid, den har ingen uppfattning om tidszon eller sommartid. När hwclock får veta att den är i lokal tid, antar den därför att den är i "rätt" lokal tid och gör inga justeringar av den tid som läses från den.

Linux hanterar sommartidsändringar på ett transparent sätt endast när maskinvaruklockan hålls i UTC-tidsskalan. Detta görs enkelt för systemadministratörer eftersom hwclock använder lokal tid för utdata och som argument för flaggan --date.

POSIX-system, som Linux, är utformade för att systemklockan ska fungera i UTC-tidsskalan. Hårdvaruklockans syfte är att initiera systemklockan, så det är vettigt att även hålla den i UTC.

Linux försöker dock hantera att hårdvaruklockan befinner sig i den lokala tidsskalan. Detta är främst för dubbelstart med äldre versioner av MS Windows. Från och med Windows 7 är det meningen att registernyckeln RealTimeIsUniversal ska fungera korrekt så att maskinvaruklockan kan hållas i UTC.

  POSIX kontra RIGHT"

En diskussion om konfiguration av datum och tid skulle vara ofullständig utan att ta upp tidszoner, och detta täcks för det mesta väl av tzset(3). Ett område som inte verkar ha någon dokumentation är den "rätta" katalogen för Time Zone Database, ibland kallad tz eller zoneinfo.

Det finns två separata databaser i zoneinfo-systemet, posix och "right". "Right" (som nu heter zoneinfo-leaps) innehåller skottsekunder och posix gör det inte. För att använda den "rätta" databasen måste systemklockan ställas in på (UTC + skottsekunder), vilket motsvarar (TAI - 10). Detta gör det möjligt att beräkna det exakta antalet sekunder mellan två datum som korsar en skottsekundeepok. Systemklockan konverteras sedan till rätt civil tid, inklusive UTC, genom att använda de "rätta" tidszonsfilerna som subtraherar skottsekunderna. Observera: denna konfiguration betraktas som experimentell och är känd för att ha problem.

För att konfigurera ett system att använda en viss databas måste alla filer som finns i dess katalog kopieras till roten av /usr/share/zoneinfo. Filer används aldrig direkt från posix- eller "right"-underkatalogerna, t.ex. TZ='right/Europe/Dublin'. Denna vana började bli så vanlig att uppströmsprojektet zoneinfo omstrukturerade systemets filträd genom att flytta posix- och "höger"-underkatalogerna från zoneinfo-katalogen till syskonkataloger:

/usr/share/zoneinfo, /usr/share/zoneinfo-posix, /usr/share/zoneinfo-leaps

Tyvärr ändrar vissa Linux-distributioner tillbaka till den gamla trädstrukturen i sina paket. Så problemet med att systemadministratörer hamnar i "rätt" underkatalog kvarstår. Detta gör att systemets tidszon konfigureras för att inkludera skottsekunder medan zoneinfo-databasen fortfarande är konfigurerad för att utesluta dem. När sedan en applikation som ett världsklocka behöver tidszonsfilen för South_Pole, eller en e-post-MTA, eller hwclock behöver UTC-tidszonsfilen, hämtar de den från roten till /usr/share/zoneinfo, eftersom det är vad de ska göra. Dessa filer utesluter skottsekunder, men systemklockan inkluderar dem nu, vilket orsakar en felaktig tidsomvandling.

Att försöka blanda och matcha filer från dessa separata databaser kommer inte att fungera, eftersom de kräver att systemklockan använder olika tidsskalor. Zoneinfo-databasen måste konfigureras för att använda antingen posix eller 'right', enligt beskrivningen ovan, eller genom att tilldela en databassökväg till miljövariabeln TZDIR.

AVSLUTSSTATUS

Ett av följande utgångsvärden kommer att returneras:

EXIT_SUCCESS ('0' på POSIX-system)
    Framgångsrikt programgenomförande.

EXIT_FAILURE ('1' på POSIX-system)
    Åtgärden misslyckades eller kommandosyntaxen var inte giltig.

MILJÖ

TZ
    Om denna variabel är inställd har dess värde företräde framför den systemkonfigurerade tidszonen.

TZDIR
    Om denna variabel är inställd har dess värde företräde framför den systemkonfigurerade sökvägen till tidszonsdatabasen.

FILER

/etc/adjtime
    Konfigurations- och tillståndsfilen för hwclock. Se även adjtime_config(5).

/etc/localtime
    Filen för systemets tidszon.

/usr/share/zoneinfo/
    Databasens katalog för systemets tidszon.

Device files hwclock may try for Hardware Clock access: /dev/rtc /dev/rtc0 /dev/misc/rtc /dev/efirtc /dev/misc/efirtc

SE ÄVEN

date(1), adjtime_config(5), adjtimex(8), gettimeofday(2), settimeofday(2), crontab(1p), tzset(3)

UPPHOVSPERSONER

Skrivet av september 1996, baserat på arbete som utförts på programmet clock(8) av Charles Hedrick, Rob Hooft och Harald Koenig. Se källkoden för fullständig historik och krediteringar.

FELRAPPORTERING

För felrapporter, använd

TILLGÄNGLIGHET

Kommandot hwclock ingår i paketet util-linux som kan hämtas från