Namn

ntpd – Network Time Protocol (NTP) daemon

Synopsis

ntpd ]

Beskrivning

Programmet ntpd är en operativsystemdemon som ställer in och upprätthåller systemets tid på dygnet i synkronisering med Internets standardtidsservrar. Det är en fullständig implementering av Network Time Protocol (NTP) version 4, men är även kompatibelt med version 3, enligt definitionen i RFC-1305, och versionerna 1 och 2, enligt definitionerna i RFC-1059 respektive RFC-1119. ntpd utför de flesta beräkningar med 64-bitars aritmetik med flytande punkter och gör relativt klumpiga 64-bitars operationer med fast punkt endast när det är nödvändigt för att bevara den ultimata precisionen, cirka 232 pikosekunder. Även om den ultimata precisionen inte är möjlig att uppnå med dagens vanliga arbetsstationer och nätverk kan den komma att krävas med framtida gigahertz CPU-klockor och gigabit LAN:s.

Hur Ntp fungerar

Programmet ntpd fungerar genom att utbyta meddelanden med en eller flera konfigurerade servrar med bestämda pollintervaller. När programmet startas, oavsett om det är första gången eller efterföljande gånger, krävs flera utbyten från majoriteten av dessa servrar så att signalbehandlings- och begränsningsalgoritmerna kan ackumulera och bearbeta data och ställa in klockan. För att skydda nätet från störningar förskjuts det första avropsintervallet för varje server med ett intervall som är slumpmässigt fördelat över några sekunder. Med standardintervallet på 64 sekunder kan det gå flera minuter innan klockan ställs in. Den inledande fördröjningen för att ställa klockan kan minskas med nyckelordet iburst med kommandot för serverkonfiguration, enligt beskrivning på sidan Konfigurationsalternativ.

De flesta operativsystem och maskinvara i dag innehåller ett TOY-chip (Time-of-Year) för att upprätthålla tiden under perioder då strömmen är avstängd. När maskinen startas upp används chipet för att initialisera operativsystemets tid. När maskinen har synkroniserats med en NTP-server korrigerar operativsystemet chipet från tid till annan. Om det inte finns något TOY-chip eller om dess tid av någon anledning skiljer sig mer än 1000 sekunder från servertiden, antar ntpd att något måste vara fruktansvärt fel och att den enda tillförlitliga åtgärden är att operatören ingriper och ställer in klockan för hand. Detta får ntpd att avsluta med ett panikmeddelande till systemloggen. Alternativet -g åsidosätter denna kontroll och klockan kommer att ställas in på servertiden oberoende av chiptiden. För att skydda mot trasig hårdvara, t.ex. när CMOS-batteriet går sönder eller klockräknaren blir defekt, när klockan väl har ställts in kommer ett fel som är större än 1000s att leda till att ntpd avslutas i alla fall.

Under vanliga förhållanden justerar ntpd klockan i små steg så att tidsskalan i praktiken är kontinuerlig och utan diskontinuiteter. Under förhållanden med extrem nätverksöverbelastning kan jitteret för rundgångsfördröjningen överstiga tre sekunder och synkroniseringsavståndet, som är lika med halva rundgångsfördröjningen plus felbudgettermerna, kan bli mycket stort. ntpd-algoritmerna förkastar provförskjutningar som överstiger 128 ms, såvida inte det intervall under vilket ingen provförskjutning är mindre än 128 ms överstiger 900 sekunder. Det första samplet därefter, oavsett förskjutning, ställer klockan till den angivna tiden. Genom att praktisera detta minskas andelen falska larm där klockan är felställd till en försvinnande liten förekomst.

Som ett resultat av detta beteende, när klockan väl har ställts in, avviker den mycket sällan mer än 128 ms, även i extrema fall av överbelastning av nätverksbanan och jitter. Ibland, särskilt när ntpd startas för första gången, kan felet överstiga 128 ms. Detta kan ibland leda till att klockan ställs in bakåt om den lokala klocktiden ligger mer än 128 s i framtiden i förhållande till servern. I vissa tillämpningar kan detta beteende vara oacceptabelt. Om alternativet -x finns med på kommandoraden kommer klockan aldrig att steppas och endast slewkorrigeringar kommer att användas.

Frågorna bör undersökas noggrant innan man bestämmer sig för att använda alternativet -x. Den maximala möjliga slew-hastigheten är begränsad till 500 ppm (parts-per-million) som en följd av de korrekthetsprinciper på vilka NTP-protokollet och algoritmdesignen är baserade. Som ett resultat av detta kan det ta lång tid för den lokala klockan att konvergera till en acceptabel förskjutning, cirka 2 000 s för varje sekund klockan är utanför det acceptabla intervallet. Under detta intervall kommer den lokala klockan inte att överensstämma med någon annan nätverksklocka och systemet kan inte användas för distribuerade tillämpningar som kräver korrekt synkroniserad nätverkstid.

Trots ovanstående försiktighetsåtgärder kan ibland, när stora frekvensfel förekommer, de resulterande tidsförskjutningarna sträcka sig utanför intervallet 128 ms och en korrigering av steg- eller svängningstiden krävs. Om frekvensfelet efter en sådan korrigering är så stort att det första provet ligger utanför det acceptabla intervallet, går ntpd in i samma tillstånd som när filen ntp.drift inte finns. Avsikten med detta beteende är att snabbt korrigera frekvensen och återställa driften till det normala spårningsläget. I de mest extrema fallen (time.ien.it kommer jag att tänka på) kan det förekomma tillfälliga steg- och vridkorrigeringar och efterföljande frekvenskorrigeringar. Det hjälper i dessa fall att använda nyckelordet burst när man konfigurerar servern.

Frekvensdisciplin

Ntpd:s beteende vid uppstart beror på om frekvensfilen, vanligtvis ntp.drift, finns. Denna fil innehåller den senaste uppskattningen av klockfrekvensfelet. När ntpd startas och filen inte finns, går ntpd in i ett speciellt läge som är utformat för att snabbt anpassa sig till particularsystemets klockoscillators tids- och frekvensfel. Detta tar ungefär 15 minuter, varefter tiden och frekvensen sätts till nominella värden och thentpd går in i normalläge, där tiden och frekvensen kontinuerligt följs upp i förhållande till servern. Efter en timme skapas frekvensfilen och den aktuella frekvensförskjutningen skrivs in i den. När ntpd startas och filen existerar initialiseras ntpd-frekvensen från filen och går omedelbart in i normalläge. Därefter skrivs den aktuella frekvensförskjutningen till filen med timintervaller.

Operationslägen

ntpd kan fungera i något av flera lägen, inklusive symmetriskt aktivt/passivt, klient/server broadcast/multicast och manycast, enligt beskrivningen på sidanAssociation Management. Den arbetar normalt kontinuerligt samtidigt som den övervakar små förändringar i frekvensen och trimmar klockan för ultimatprecision. Den kan dock fungera i ett engångsläge där tiden ställs in från en extern server och frekvensen ställs in från en tidigare registrerad frekvensfil. En broadcast/multicast- eller manycast-klient kan upptäcka fjärrservrar, beräkna korrektionsfaktorer för spridningsfördröjning mellan server och klient och konfigurera sig själv automatiskt. Detta gör det möjligt att installera en flotta av arbetsstationer utan att ange konfigurationsdetaljer som är specifika för den lokala miljön.

Som standard körs ntpd i kontinuerligt läge där var och en av eventuellt flera externa servrar frågas av med intervaller som bestäms av en intrikat statemaskin. Statsmaskinen mäter den tillfälliga rundgångsfördröjningen jitter och oscillatorfrekvensens vandring och bestämmer det bästa pollintervallet med hjälp av en heuristisk algoritm. Vanligtvis, och i de flesta driftsmiljöer, kommer tillståndsmaskinen att börja med intervaller på 64 s och så småningom öka i steg till 1024 s. En liten mängd slumpmässig variation införs för att undvika att servrarna blir för många. Om en server skulle bli ouppnåelig under en viss tid ökas dessutompollintervallet stegvis till 1024s för att minska nätverksöverbelastningen.

I vissa fall kan det vara opraktiskt för ntpd att köras kontinuerligt. En vanlig lösning har varit att köra ntpdate-programmet från ett cronjobb vid bestämda tidpunkter. Detta program har dock inte de hantverksmässiga algoritmerna för signalbehandling, felkontroll och begränsning som ntpd har Alternativet-q är avsett för detta ändamål. Genom att ställa in det här alternativet kommer ntpd att avslutas strax efter att klockan ställts in för första gången med dekonfigurerade servrarna. Förfarandet för den första inställningen av klockan är detsamma som i kontinuerligt läge; de flesta tillämpningar kommer förmodligen att vilja ange nyckelordetiburst med kommandot för serverkonfiguration. Med det här nyckelordet utbyts en mängd meddelanden för att groom data och klockan ställs in på ungefär 10 s. Om inget hörs efter ett par minuter tar daemonerna timeout och avslutas. Efter en lämplig sorgeperiod kan ntpdate-programmet avvecklas.

När det finns kärnstöd för att disciplinera klockfrekvensen, vilket är fallet för standard-Solaris, Tru64, Linux och FreeBSD, finns det en användbar funktion för att disciplinera klockfrekvensen. Först körs ntpd i kontinuerligt läge med utvalda servrar för att mäta och registrera den inneboende klockfrekvensförskjutningen i frekvensfilen. Det kan ta några timmar innan frekvensen och förskjutningen har stabiliserats. Därefter stoppas ntpd och körs i enstaka läge vid behov. Vid varje start läses frekvensen från filen och initialiserar kärnfrekvensen.

Poll Interval Control

Denna version av NTP innehåller en intrikat tillståndsmaskin för att minska nätverksbelastningen samtidigt som man upprätthåller en synkroniseringskvalitet som är förenlig med den observerade jittern och vandringen. Det finns ett antal sätt att skräddarsy verksamheten för att öka noggrannheten genom att minska intervallet eller för att minska nätverksbelastningen genom att öka det. Användaren rekommenderas dock att noga överväga konsekvenserna av att ändra intervallet för polljustering från standardminimum 64 s till standardmaximum 1024 s. Standardminimum kan ändras med kommandot tinker minpoll till ett värde som inte är mindre än 16 s. Detta värde används för alla konfigurerade associationer, såvida det inte åsidosätts av alternativet minpoll på konfigurations kommandot. Observera att de flesta enhetsdrivrutiner inte kommer att fungera korrekt om pollintervallet är mindre än 64 s och att broadcast-server- och manycast-klientassociationerna också kommer att använda standardvärdet, om det inte åsidosätts.

I vissa fall som involverar uppringning eller avgiftsbelagda tjänster kan det vara användbart att öka det minsta intervallet till några tiotals minuter och det största intervallet till en dag eller så. Under normala driftsförhållanden kommer intervallet att ökas i steg från minimum till maximum när klockdisciplinslingan har stabiliserats. Detta förutsätter dock att det inneboende klockfrekvensfelet är tillräckligt litet för att disciplineringsslingan skall kunna korrigera det. Slingans upptagningsområde är 500 PPM med ett intervall på 64 s, vilket minskar med en faktor två för varje fördubbling av intervallet. Vid ett minimum av 1 024 s, till exempel, är fångstområdet endast 31 PPM. Om det inneboende felet är större än så måste driftfilen ntp.drift skräddarsys speciellt för att minska det kvarvarande felet till under denna gräns. när detta väl är gjort uppdateras driftfilen automatiskt en gång i timmen och finns tillgänglig för att initialisera frekvensen vid efterföljande omstarter av daemon.

the Huff-n’-puff Filter

I scenarier där en avsevärd mängd data skall laddas ner eller laddas upp via telefonmodem kan kvaliteten på tidtagningen försämras allvarligt. Detta beror på att de differentiella fördröjningarna i de två överföringsriktningarna kan vara ganska stora. I många fall är de skenbara tidsfelen så stora att de överskrider stegtröskeln och en stegkorrigering kan ske under och efter dataöverföringen.

Huff-n’-puff-filtret är konstruerat för att korrigera den skenbara tidsförskjutningen i dessa fall. Det är beroende av kunskap om spridningsfördröjningen när ingen annan trafik är närvarande. I vanliga scenarier inträffar detta under andra tider än arbetstid. Filtret har ett skiftregister som minns den minsta fördröjningen under det senaste intervallet som vanligtvis mäts i timmar. Under förhållanden med kraftig fördröjning korrigerar filtret den synliga förskjutningen med hjälp av förskjutningens tecken och skillnaden mellan den synliga fördröjningen och den minsta fördröjningen. Filtrets namn återspeglar den negativa (huff) och positiva (puff) korrigeringen, som beror på förskjutningens tecken.

Filtret aktiveras av kommandot tinker och nyckelordet huffpuff, enligt beskrivningen på sidan Diverse alternativ.

Anmärkningar

Om stöd för NetInfo är inbyggt i ntpd kommer ntpd att försöka läsa sin konfiguration från NetInfo om standardinställningen ntp.conf-filen inte kan läsas och ingen fil anges med alternativet -c.

I sammanhang där ett värdnamn förväntas tvingar en -4-kvalificering före värdnamnet DNS-upplösning till IPv4-namnområdet, medan en -6-kvalificering tvingar DNS-upplösning till IPv6-namnområdet.

Flera interna ntpd-variabler kan visas och konfigurationsalternativ ändras medan ntpd körs med hjälp av hjälpprogrammen ntpq ochntpdc.

När ntpd startar tittar den på värdet av umask, och om det är noll kommer ntpd att sätta umask till 022

Om inte alternativet -n, -d eller -D används ändrar ntpd den aktuella arbetskatalogen till rotkatalogen, så alla alternativ ellerkommandon som anger sökvägar måste använda en absolut sökväg eller en sökväg som är relativ till roten.

Optioner för kommandoraden

-4 Forcera DNS-upplösning av värdnamn till IPv4-namnområdet. -6 Tvinga DNS-upplösning av värdnamn till IPv6-namnområdet. -a Kräver kryptografisk autentisering för broadcast-klient, multicast-klient och symmetriska passiva associationer. Detta är standardinställningen. -A Kräv inte kryptografisk autentisering för broadcast-klient, multicast-klient och symmetriska passiva associationer. Detta är nästan aldrig en bra idé. -b Aktivera klienten att synkronisera med sändningsservrar. -c conffile Ange namn och sökväg för konfigurationsfilen, standard /etc/ntp.conf -d Ange felsökningsläge. Det här alternativet kan förekomma mer än en gång, och varje förekomst indikerar en mer detaljerad visning. -D level Ange felsökningsnivå direkt. -f driftfile Ange namn och sökväg för frekvensfilen. Det här är samma operation som konfigurationskommandot driftfile driftfile driftfile. -g Normalt avslutas ntpd med ett meddelande till systemloggen om förskjutningen överskrider paniktröskeln, som är 1000 s som standard. Med det här alternativet kan thetime sättas till vilket värde som helst utan begränsning; detta kan dock endast ske en gång. Om tröskelvärdet överskrids därefter avslutas ntpd med ett meddelande till systemloggen. Det här alternativet kan användas tillsammans med alternativen -q och -x. Se kommandot tinker för andra alternativ. -i jaildir Chroot servern till katalogen jaildir Detta alternativ innebär också att servern försöker ta bort rotprivilegier vid start (annars ger chroot mycket lite extra säkerhet), och det är endast tillgängligt om operativsystemet har stöd för att köra servern utan fullständiga rotprivilegier. Du kan också behöva ange ett -u-alternativ. -I iface Lyssna på gränssnittet. Det här alternativet kan förekomma ett obegränsat antal gånger. -k keyfile Ange namn och sökväg för den symmetriska nyckelfilen. Detta är samma operation som konfigurationskommandot keys keyfile. -l logfile Ange namn och sökväg för loggfilen. Standardinställningen är systemloggfilen. Detta är samma operation som kommandot logfile logfileconfiguration. -L Lyssna inte på virtuella IP:er. Standardvärdet är att lyssna. -m Lås minnet. -n Gaffla inte. -N I den utsträckning som operativsystemet tillåter, kör ntpd med högsta prioritet. -p pidfile Ange namn och sökväg till den fil som används för att registrera ntpd-process-ID. Detta är samma operation som kommandot pidfile pidfileconfiguration. -P priority I den utsträckning som operativsystemet tillåter, kör ntpd med den angivna prioriteten. -q Avsluta ntpd strax efter första gången klockan ställs in. Detta beteende efterliknar ntpdate-programmet, som ska avvecklas. Alternativen -g och -x kan användas tillsammans med det här alternativet. Observera: Kärnans tidsdisciplin är inaktiverad med det här alternativet. -r broadcastdelay Ange standardfördröjningen för spridning från broadcast/multicast-servern till den här klienten. Detta är endast nödvändigt om fördröjningen inte kan beräknas automatiskt av protokollet. -s statsdir Ange katalogsökvägen för filer som skapas av statistikfunktionen. Detta är samma operation som konfigurationskommandot statsdir statsdir statsdir. -t key Lägg till ett nyckelnummer i listan över betrodda nycklar. Detta alternativ kan förekomma mer än en gång. -u user Ange en användare, och eventuellt en grupp, att växla till. Det här alternativet är endast tillgängligt om operativsystemet har stöd för att köra servern utan fullständiga rotprivilegier. för närvarande stöds det här alternativet under NetBSD (konfigurera med –enable-clockctl) och Linux (konfigurera med –enable-linuxcaps). -U interface update interval Antal sekunder att vänta mellan skanningar av gränssnittslistor för att plocka upp nya och raderade nätverksgränssnitt. Ställ in 0 för att inaktivera dynamisk uppdatering av gränssnittslistan.Standardvärdet är att skanna var 5:e minut. -v variable-V variable Lägg till en systemvariabel som listas som standard. -x Normalt sett är tiden svängd om förskjutningen är mindre än tröskelvärdet för steget, som är 128 ms som standard, och stegvis om den är över tröskelvärdet. Detta alternativ ställer in tröskelvärdet på 600 s, vilket ligger väl inom noggrannhetsfönstret för att ställa klockan manuellt. Obs: Eftersom slew-hastigheten för typiska Unix-kärnor är begränsad till 0,5 ms/s, kräver varje sekunds justering ett amorteringsintervall på 2000 s. Således kommer en justering så mycket som 600 s att ta nästan 14 dagar att slutföra.Det här alternativet kan användas tillsammans med alternativen -g och -q. Se kommandot tinker för andra alternativ. Observera: Kärnans tidsdisciplin är inaktiveradmed detta alternativ.

konfigurationsfilen

Ordinarie läser ntpd konfigurationsfilen ntp.conf vid start för att bestämma synkroniseringskällor och driftlägen. det är också möjligt att ange en fungerande, om än begränsad, konfiguration helt och hållet på kommandoraden, vilket gör att en konfigurationsfil inte behövs. Detta kan vara särskilt användbart när den lokala värddatorn ska konfigureras som en broadcast/multicast-klient, där alla kamrater bestäms genom att lyssna på broadcasts vid starttidpunkten.

Vanligtvis installeras konfigurationsfilen i katalogen /etc, men den kan också installeras någon annanstans (se kommandoradsalternativet -c conffile). Filformatet liknar andra Unix-konfigurationsfiler – kommentarer börjar med ett #-tecken och sträcker sig till linjens slut; tomma rader ignoreras.

Konfigurationskommandon består av ett inledande nyckelord följt av en lista med argument, varav vissa kan vara valfria, separerade med blanksteg. Kommandon kan inte fortsätta över flera rader. Argumenten kan vara värdnamn, värdadresser skrivna i numerisk form i punktform, heltal, flyttal (när man anger tider i sekunder) och textsträngar. Valfria argument avgränsas med i följande beskrivningar, medan alternativ avgränsas med | Notationen betyder en valfri, obegränsad upprepning av den sista punkten före

Exitkoder

En exitkod som inte är noll indikerar ett fel. Alla felmeddelanden loggas som standard i systemloggen.

Avgångskoden är 0 endast när ntpd avslutas av en signal, eller när alternativet -q används och ntpd framgångsrikt ställer in systemklockan.

Se även

ntp.conf(5), ntpq(8), ntpdc(8)