VPS klok loopt niet gelijk: oorzaken en oplossingen

Waarom de klok van uw VPS afwijkt

De klok van een VPS wijkt af omdat er geen correctie plaatsvindt. De kernel telt de tijd op basis van een hardware-teller die iets te snel of te langzaam loopt. Zonder actieve tijdsynchronisatieclient groeit deze kleine afwijking elk uur. Binnen een virtuele machine is er een tweede oorzaak: uw guest deelt een fysieke CPU met andere guests. De momenten waarop de guest niet wordt ingepland, zijn momenten waarop deze de tijd niet kan bijhouden.

Op een moderne KVM-guest is de teller zelf zelden het werkelijke probleem. De paravirtual kvm-clock-bron leest een waarde die door de host wordt bijgehouden, waardoor een gezonde guest de tijd van de host nauwkeurig volgt. Klokken die zichtbaar onjuist zijn, wijken meestal af om een simpelere reden. Er draait geen sync-daemon, er draaien twee daemons die elkaar tegenwerken, of uitgaand UDP-poort 123 verlaat het netwerk van uw provider niet. Een guest ontleent zijn tijdsdiscipline aan de host of aan NTP (network time protocol), niet aan zijn eigen oscillator.

Wat een onjuiste klok daadwerkelijk kapotmaakt

• TOTP (time-based one-time password) tweefactorcodes komen niet meer overeen, waardoor u wordt buitengesloten van een server waarvan het wachtwoord en de sleutel beide correct zijn.
• Een certificaat dat een minuut geleden is uitgegeven wordt geweigerd en curl geeft SSL certificate problem: certificate is not yet valid weer.
• apt update weigert een repository met E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s).
• Geplande taken worden op het verkeerde moment uitgevoerd, en een klok die verspringt kan ertoe leiden dat een taak twee keer wordt uitgevoerd terwijl een andere wordt overgeslagen.
• Logs van twee servers kunnen niet op elkaar worden afgestemd, waardoor een tijdlijn van een incident op basis van giswerk moet worden samengesteld.

De tolerantie is kleiner dan de meeste mensen verwachten. De onderstaande cijfers zijn gedocumenteerde standaardwaarden, geen metingen uit een test.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Een TOTP-code wordt berekend op basis van een teller die elke 30 seconden verspringt, en de meeste verificatiesystemen accepteren één stap aan weerszijden. Een halve minuut afwijking in elke richting is het volledige budget. Kerberos is veel vergevingsgezinder, met een standaard toegestane afwijking van 300 seconden. Een certificaat is totaal niet vergevingsgezind: dit wordt gecontroleerd aan de hand van vaste tijdstippen met een respijtperiode van 0 seconden, waardoor een klok die één seconde voorloopt een certificaat weigert dat volledig geldig is.

De drie klokken, en welke van belang is

De systeemklok is de klok die ertoe doet. Dit is de CLOCK_REALTIME van de kernel: het aantal seconden sinds 1 januari 1970 UTC, dat in het geheugen wordt bijgehouden en door alles wat een tijdstempel plaatst, wordt uitgelezen. Logregels, certificaatcontroles, TOTP-codes en bestandswijzigingstijden zijn hier allemaal van afhankelijk. Wanneer iemand zegt dat de tijd van de server onjuist is, bedoelen zij deze klok.

De hardwareklok, ook wel de RTC (real time clock) genoemd, is een afzonderlijke teller die blijft lopen terwijl de machine uitgeschakeld is. Op een fysieke machine is dit een chip met een batterij. Binnen een guest wordt deze geëmuleerd door de hypervisor, waardoor het grotendeels een artefact van de host is. Linux leest deze één keer uit bij het opstarten voor een beginwaarde en houdt daarna zijn eigen telling bij. timedatectl toont deze op de RTC time-regel. Debug niet op basis van die regel op een VPS, omdat deze informatie geeft over de tijd zoals de host die ziet, in plaats van over de synchronisatiestatus van uw systeemklok. In een container is er meestal helemaal geen /dev/rtc, waardoor hwclock --show faalt met hwclock: Cannot access the Hardware Clock via any known method..

De clocksource is het mechanisme waarmee de kernel telt tussen die uitlezingen door. Vraag uw kernel welke bron deze heeft gekozen:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Op KVM ziet u meestal kvm-clock. Deze leest een waarde die door de host wordt bijgehouden, en dat is de reden waarom een KVM-guest zonder NTP-client toch een tijdje redelijk gelijk blijft lopen. tsc is de eigen teller van de CPU. Xen-guests rapporteren xen, en Hyper-V-guests rapporteren een hyperv-bron. Wijzig deze instelling niet tenzij u een gemeten reden heeft om dit te doen, omdat de kernel al de beste bron kiest die hij op die hardware vertrouwt.

Sommige hosts stellen ook een PTP-apparaat (precision time protocol) beschikbaar aan de guest, waardoor chrony de hostklok rechtstreeks kan lezen in plaats van via het netwerk. Het is de moeite waard om dit te controleren; op een gedeelde VPS is dit vaak niet beschikbaar:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Als modprobe faalt of er verschijnt geen apparaat, dan biedt uw host dit niet aan en is netwerk-NTP de oplossing. Als clock_name de KVM virtual clock benoemt, kan chrony deze gebruiken met een refclock PHC /dev/ptp0 poll 2-regel in de configuratie.

De tijdstatus op uw eigen machine uitlezen

Begin met één commando. Dit beantwoordt de vraag "wordt deze klok door iets bijgehouden" in één scherm.

timedatectl

Lees deze regels in plaats van te vertrouwen op een getal dat u zich herinnert:

• Local time en Universal time zijn hetzelfde moment, weergegeven in uw tijdzone en in UTC. Als deze identiek zijn, staat de machine al op UTC.
• RTC time is de hardwareklok zoals hierboven beschreven. Op een VPS kunt u dit negeren.
• Time zone is wat het systeem gebruikt om de lokale tijd te formatteren.
• System clock synchronized is de eigen vlag van de kernel. Een tijd-daemon stelt deze in zodra hij zijn bronnen vertrouwt, dus no betekent dat niets deze klok heeft bijgestuurd sinds het opstarten.
• NTP service rapporteert specifiek over systemd-timesyncd. n/a is normaal op een machine die chrony draait, omdat timesyncd daar niet is geïnstalleerd. System clock synchronized: yes samen met NTP service: n/a betekent dat chrony het werk doet en de kernel dit bevestigt.

Vraag vervolgens hoe groot de afwijking is. Schat dit niet in door naar uw telefoon te kijken. Als chrony draait:

chronyc tracking
chronyc sources -v

chronyc tracking toont de getallen die de vraag beantwoorden. System time is de huidige afwijking van de NTP-tijd, gevolgd door het woord fast of slow. Last offset is de omvang van de meest recente correctie. Frequency is de afwijkingssnelheid die chrony in uw klok heeft gemeten en waarvoor het al compenseert. Leap status hoort Normal aan te geven. Als er Not synchronised staat en Reference ID is 00000000 (), dan heeft chrony nog geen bron vastgesteld.

chronyc sources -v drukt een legenda boven de lijst af, zodat u de symbolen niet hoeft te onthouden. Twee kolommen bevatten de meeste informatie. Het statuskarakter aan het begin van elke regel geeft aan hoe chrony die bron beoordeelt, waarbij * de bron markeert die momenteel wordt gebruikt en ? op elke regel betekent dat er geen antwoord komt. Reach is de antwoordgeschiedenis van de laatste acht polls, weergegeven in octaal: 377 betekent dat alle acht zijn beantwoord, 0 betekent dat er geen zijn beantwoord.

Als systemd-timesyncd de beheerder is:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status toont de server waarmee gecommuniceerd wordt, het poll-interval en een Offset-waarde. Als het commando een foutmelding over de service geeft in plaats van de status te tonen, is timesyncd niet de actieve daemon op deze machine; dat is op zichzelf al het antwoord op uw vraag.

Voor een grove controle tegen de buitenwereld zonder extra tools, vergelijkt u uw klok met een publieke HTTP Date-header, die wordt geserveerd in GMT met een resolutie van één seconde:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Een verschil van een seconde of twee is hier normaal en betekent niets. Een verschil van een minuut is een fout die u moet corrigeren.

chrony of systemd-timesyncd op een VPS

Ubuntu en Debian leveren standaard systemd-timesyncd. Dit is een SNTP-client (simple network time protocol): deze bevraagt één server tegelijk en corrigeert de klok in de richting van die server. Voor een machine die online blijft en waarvan de tijd bij benadering correct is, volstaat dit en het verbruikt vrijwel geen resources.

chrony is een volledige NTP-implementatie en de betere standaardkeuze voor een virtuele machine, om redenen die u in de output van het programma zelf kunt zien. Het bevraagt meerdere bronnen tegelijk en negeert bronnen die onderling afwijken. Het meet de afwijking van uw klok en schrijft deze naar een drift-bestand, waardoor het de neiging van de klok corrigeert in plaats van elk meetpunt na te jagen. Het herstelt ook snel van twee zaken die een VM wel doet, maar een fysieke server niet: de VM kan door de host worden gepauzeerd en kan tijdens het draaien naar een andere host worden verplaatst. Wanneer een PTP-apparaat van de host wordt aangeboden, is het chrony dat dit uitleest.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Lees de apt-output terwijl deze draait. Op Debian en Ubuntu bieden zowel de chrony- als de systemd-timesyncd-pakketten time-daemon aan, waardoor apt timesyncd verwijdert zodra u chrony installeert. Dit is correct en gewenst. Draai nooit beide tegelijk, omdat twee daemons die dezelfde klok proberen in te stellen elkaar tegenwerken; de gerapporteerde offset is in dat geval onbetrouwbaar. Installeer op Rocky en AlmaLinux met sudo dnf install -y chrony, waarbij de unit chronyd heet in plaats van chrony.

Het configuratiebestand is /etc/chrony/chrony.conf op Debian en Ubuntu, en /etc/chrony.conf op Rocky en Alma. De standaardinstelling van de distributie is al zinvol voor een VPS, dus pas deze alleen aan als daar een reden voor is. Twee richtlijnen zijn belangrijk om te begrijpen:

• pool- en server-regels benoemen de tijdsbronnen. Door iburst toe te voegen, geeft u chrony de opdracht om bij het opstarten een snelle burst te sturen, zodat de eerste synchronisatie binnen seconden in plaats van minuten plaatsvindt.
• makestep bepaalt wanneer chrony de klok verspringt in plaats van deze geleidelijk bij te stellen. Controleer wat uw configuratie aangeeft met grep -n makestep /etc/chrony/chrony.conf. De standaardwaarde voor Debian en Ubuntu, makestep 1 3, betekent het volgende: tijdens de eerste drie updates nadat chronyd is gestart, wordt de klok versprongen als de afwijking meer dan één seconde bedraagt; daarna wordt de tijd uitsluitend via slewing gecorrigeerd.

Als u wilt dat het tijdverkeer wordt geverifieerd tegen manipulatie onderweg, ondersteunen chrony 4 en later NTS (network time security). Bevestig eerst uw versie met chronyd -v en houd er rekening mee dat NTS naast UDP 123 ook uitgaand TCP-poort 4460 open moet hebben:

server time.cloudflare.com iburst nts

Herstart en verifieer de status voordat u erop vertrouwt. Een configuratie die niet kan worden geparseerd, laat u achter zonder tijd-daemon, en de klok zal u daar niet voor waarschuwen.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Waarom een klok die minuten afwijkt, afwijkend blijft

Een time daemon heeft twee manieren om een afwijking te corrigeren. Slewing versnelt of vertraagt de klok totdat de fout is verdwenen; hierbij blijft de tijd vooruitlopen en worden tijdstempels nooit herhaald of overgeslagen. Stepping springt direct naar de juiste waarde; dit is snel, maar kan de klok ook achteruit zetten. Achteruit springen is riskant voor processen die de verstreken tijd meten op basis van de systeemklok, dus geven beide daemons de voorkeur aan slewing.

Die voorkeur is de reden waarom een sterk afwijkende klok lang onjuist kan blijven. chrony voert alleen een step uit binnen het venster dat makestep toestaat, wat standaard de eerste paar updates na het starten van de daemon is. Een chronyd die al een week draait en vervolgens een afwijking van veertig seconden detecteert, zal deze via slewing corrigeren, en veertig seconden slewen duurt veel langer dan wenselijk is. Forceer dit eenmalig en bewust op een rustig moment:

sudo chronyc makestep
chronyc tracking

chronyc tracking zou nu een System time offset nabij nul moeten rapporteren, en Last offset zou de grootte moeten tonen van wat zojuist is gecorrigeerd. Denk goed na voordat u dit uitvoert op een drukke databasehost, omdat een klok die achteruit springt software in de war kan brengen die ervan uitgaat dat de tijd alleen vooruit beweegt. Het herstarten van de daemon is de mildere versie van dezelfde correctie, aangezien het makestep venster bij het opstarten opnieuw wordt geopend.

Containers delen de klok van de host

Een container heeft geen eigen klok, dus er valt binnenin niets te synchroniseren. Linux time namespaces virtualiseren alleen de monotonic en boot-time klokken. CLOCK_REALTIME wordt niet gevirtualiseerd, wat betekent dat een container dezelfde systeemklok leest als de host waarop deze draait. Herstel de klok op de host en elke container op die host is op hetzelfde moment hersteld.

Hieruit volgen enkele consequenties. Installeer geen chrony of ntpd in een image, omdat dit in het beste geval niets doet. Het instellen van de datum in een niet-geprivilegieerde container mislukt met date: cannot set date: Operation not permitted, aangezien de kernel CAP_SYS_TIME vereist voor die aanroep. Het verlenen van CAP_SYS_TIME geeft de container geen eigen klok; het geeft de container de mogelijkheid om de klok van de host te wijzigen en daarmee ook de klok van elke andere container.

Een andere tijdzone in een container is geen klokprobleem. Een image met een eigen /etc/localtime toont hetzelfde tijdstip geformatteerd voor een andere zone, waardoor date onjuist lijkt terwijl de klok correct is. Stel TZ=UTC in de containeromgeving in en de verwarring verdwijnt. De runtime die u heeft gekozen verandert hier niets aan, en de vergelijking tussen rootless Podman en Docker behandelt wat er wel verandert.

Tijdzones: UTC op de server, lokale tijd voor mensen

Stel de machine in op UTC en wijzig dit niet.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC kent geen zomertijd, en dat is het enige argument dat telt. Een dagelijkse taak om 02:30 in een tijdzone die zomertijd hanteert, wordt op de dag dat de klok wordt teruggezet twee keer uitgevoerd, en op de dag dat de klok vooruitgaat helemaal niet. man 8 cron documenteert de speciale afhandeling voor verschuivingen van minder dan drie uur: taken die worden overgeslagen door een voorwaartse sprong worden kort na de wijziging uitgevoerd, en taken die in een herhaald uur vallen door een achterwaartse sprong worden niet een tweede keer uitgevoerd. Dat gedrag is redelijk, maar het is nog steeds gedrag waar u om 03:00 uur niet over na zou moeten hoeven denken. Onder UTC wordt de taak één keer per dag uitgevoerd, elke dag van het jaar. Als een taak van u volledig ontbreekt in plaats van op een vreemd tijdstip te worden uitgevoerd, is de redenen waarom een cron job stilletjes nooit draait de meest waarschijnlijke verklaring.

Hetzelfde argument geldt voor het lezen van logs. journalctl formatteert tijdstempels in de lokale tijdzone van het systeem, en journalctl --utc dwingt UTC af. Twee servers in twee tijdzones veranderen elk incident in een conversieoefening, en conversies die onder druk worden uitgevoerd leiden tot een verkeerde interpretatie van de tijdlijn. Houd de systemen op UTC, sla tijdstempels op in UTC en converteer pas op het moment dat een mens ze leest. Iedereen die voor één commando een lokale weergave wil, kan daarom vragen zonder de machine aan te passen:

TZ=Europe/Berlin date

Nog één regel in de output van timedatectl hoort bij deze sectie. RTC in local TZ zou no moeten lezen. Het instellen op yes is een workaround voor het dual-booten van Windows op een laptop, en op een server voegt het alleen een offset toe waar iemand later over kan struikelen. Wanneer dit is ingesteld, geeft timedatectl een waarschuwing dat het systeem is geconfigureerd om de RTC-tijd in de lokale tijdzone te lezen.

Problemen oplossen op basis van symptomen

Uw tweefactorcode wordt op één server geweigerd. Controleer de klok voordat u iets anders onderzoekt. De code is afkomstig van een teller die elke 30 seconden verspringt. Een server die 90 seconden achterloopt, berekent daarom een code van een stap die uw telefoon al is gepasseerd. timedatectl toont System clock synchronized: no, of chronyc tracking rapporteert een grote System time offset. Dit is een ander type fout dan een direct afgewezen sleutel, die een eigen melding geeft en wordt behandeld in de handleiding voor publickey-authenticatiefouten.

apt update meldt dat een Release-bestand nog niet geldig is. Het volledige bericht noemt de repository en de tijdsduur dat deze nog ongeldig blijft, bijvoorbeeld is not valid yet (invalid for another 1d 2h 3min 4s). Uw klok loopt achter op de datum in het Release-bestand van de repository, en die tijdsduur is een directe meting van de achterstand. Corrigeer de klok. Schakel de datumcontrole van apt niet uit om dit te omzeilen, aangezien deze controle voorkomt dat iemand u een verouderde pakketindex aanbiedt.

Elke bronregel toont de status onbereikbaar en Reach is 0. Er komt geen antwoord, dus kijk naar uitgaand verkeer in plaats van naar uw configuratie. NTP gebruikt UDP-poort 123 voor uitgaand verkeer, en sommige netwerken filteren of omleiden dit. sudo chronyc ntpdata toont tellers per bron, inclusief Total TX en Total RX. Een TX-teller die oploopt terwijl RX op nul blijft staan, betekent dat uw pakketten vertrekken maar er niets terugkomt. Dit wijst op een firewall tussen u en de bron.

De klok liep goed, maar versprong plotseling. Host-gebeurtenissen veroorzaken dit. Een herstelde snapshot, een gepauzeerde guest of een live migratie naar een andere host kan ertoe leiden dat de tijd van de guest achterloopt op de werkelijke tijd. chrony merkt dit bij de volgende poll op en corrigeert het; systemd-timesyncd wacht mogelijk eerst een lang poll-interval af. Bevestig dat de daemon start bij het opstarten met systemctl is-enabled chrony, omdat een handmatig gestarte daemon na de volgende reboot verdwenen is.

De offset is klein maar stabiliseert nooit. Kijk naar CPU-steal. Een guest die niet wordt ingepland wanneer zijn timer-interrupt moet plaatsvinden, krijgt vertraagde samples, waardoor de offset blijft schommelen in plaats van convergeren. top toont dit als het st-cijfer op de CPU-regel. CPU-steal-tijd uitlezen op een gedeelde host legt uit wat dat getal betekent en wat u eraan kunt doen.

Een zojuist uitgegeven certificaat wordt geweigerd als nog niet geldig. curl print SSL certificate problem: certificate is not yet valid, en browsers geven een vergelijkbare melding. Het certificaat is in orde; de klok die het controleert loopt achter. Beide machines kunnen de oorzaak zijn, dus controleer zowel de client als de server. Als de server die het certificaat heeft uitgegeven de verkeerde kloktijd heeft, behandelt de certbot en nginx certificaatgids de vernieuwingskant van dezelfde configuratie.

Voeg dit toe aan uw bestaande controles

Tijdsynchronisatie is een instelling die tijdens het opstarten wordt geconfigureerd, maar die maanden later geruisloos kan falen. Dit is precies het type probleem dat door een routine wordt opgemerkt, maar niet door het geheugen. Het is in twee seconden mogelijk om timedatectl en chronyc tracking samen te lezen. Voer deze uit als onderdeel van de eerste tien minuten op een nieuwe VPS, en opnieuw wanneer u de reguliere onderhoudschecklist voor Linux-servers doorloopt. Als u liever wilt dat de controle automatisch wordt uitgevoerd en een melding geeft wanneer de afwijking toeneemt, behandelt het schrijven van een systemd service en timer het patroon voor een kleine unit die volgens een schema rapporteert. Een dergelijke controle is eerder een kort script dan een daemon, dus vereist het Type=oneshot in plaats van de standaardinstelling. Het overzicht van systemd service-types legt uit waarom de verkeerde keuze resulteert in een unit die een succes rapporteert dat nooit is behaald.

FAQ

Hoe controleer ik of de klok van mijn VPS synchroon loopt?

Voer timedatectl uit en lees de regel System clock synchronized. Dit is de vlag van de kernel zelf, ingesteld door de daemon die de klok beheert; yes in combinatie met NTP service: n/a is dus normaal en correct op een machine die chrony gebruikt. Voor de grootte van de afwijking voert u chronyc tracking uit en leest u System time, of voert u timedatectl timesync-status uit en leest u Offset als systemd-timesyncd verantwoordelijk is. Voor een controle tegen een externe bron vergelijkt u date -u met de Date-header die door een willekeurige HTTPS-site wordt geretourneerd.

Moet ik chrony of systemd-timesyncd gebruiken op een VPS?

Gebruik chrony voor alles wat belangrijk is. systemd-timesyncd is een SNTP-client die één server volgt; dit volstaat voor een machine die online blijft en bij de start al redelijk op tijd loopt. chrony pollt meerdere bronnen, verwerpt bronnen die afwijken, leert de afwijking van uw klok en herstelt snel na een pauze van de host of een live migratie. Het installeren van chrony op Debian of Ubuntu verwijdert systemd-timesyncd automatisch, omdat beide pakketten time-daemon leveren. Draai nooit twee tijd-daemons tegelijkertijd.

Waarom werken mijn TOTP-codes niet op één server, maar wel overal elders?

Omdat een TOTP-code een functie is van de huidige tijd. De code komt van een teller die elke 30 seconden verspringt, dus de server en uw telefoon moeten het eens zijn over de huidige stap. De meeste verificatiesystemen accepteren een afwijking van één stap, wat ongeveer een halve minuut speling in beide richtingen geeft. Controleer timedatectl op die server. Als System clock synchronized de waarde no aangeeft, herstel dan de synchronisatie en de codes zullen weer overeenkomen zonder dat het gedeelde geheim hoeft te worden aangepast.

Kan ik de tijd instellen binnen een Docker-container?

Nee, en dat is ook niet nodig. Een container deelt de CLOCK_REALTIME van de host, omdat Linux time namespaces alleen de monotone en boot-time klokken virtualiseren. Een container zonder privileges krijgt date: cannot set date: Operation not permitted, en het toevoegen van CAP_SYS_TIME staat de container toe de klok van de host aan te passen in plaats van een eigen klok te krijgen. Synchroniseer de host. Een andere lokale tijd binnen een container is een instelling van de tijdzone; stel daarom TZ in de containeromgeving in.

Moet een server UTC of lokale tijd gebruiken?

UTC, waarbij lokale tijd wordt toegepast op het moment dat iemand de uitvoer leest. UTC verschuift nooit voor zomertijd, waardoor een dagelijkse taak het hele jaar door één keer per dag draait en tijdstempels van verschillende servers zonder conversie op één lijn liggen. Stel dit in met sudo timedatectl set-timezone UTC. Iedereen die een lokale tijdweergave wil, kan een commando laten voorafgaan door bijvoorbeeld TZ=America/New_York date; dit verandert niets aan de systeemklok.