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.

Hålla tiden utan extern synkronisering

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

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

2

3

4

5

6

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:

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.