VPS klok loopt niet gelijk: oorzaken en oplossingen

Waarom de klok van uw VPS afwijkt

De klok van een VPS wijkt af omdat deze niet wordt gecorrigeerd. De kernel telt de tijd op basis van een hardware-teller die iets te snel of te langzaam loopt. Zonder actieve tijd-synchronisatieclient 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 is 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 eenvoudigere 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 draait 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: het 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 perfect geldig is.

De drie klokken en welke relevant 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 elk proces wordt uitgelezen dat een tijdstempel plaatst. Logregels, certificaatcontroles, TOTP-codes en bestandswijzigingstijden zijn hier allemaal van afhankelijk. Wanneer iemand zegt dat de tijd van de server onjuist is, bedoelt diegene deze klok.

De hardwareklok, ook wel de RTC (real time clock) genoemd, is een afzonderlijke teller die blijft lopen terwijl de machine is uitgeschakeld. 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 tijdens 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 tijdswaarneming van de host 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 doorgaans 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 enige tijd redelijk accuraat blijft. 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, aangezien 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, waarmee chrony de hostklok rechtstreeks kan uitlezen in plaats van via het netwerk. Het is de moeite waard dit te controleren, al is het op een gedeelde VPS 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-virtuele klok 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 deze 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 time daemon zet deze zodra hij zijn bronnen vertrouwt, dus no betekent dat niets deze klok heeft gecorrigeerd 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. Vergelijk dit niet op het oog met uw telefoon. 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 grootte van de meest recente correctie. Frequency is de snelheidsfout die chrony in uw klok heeft gemeten en waarvoor het al compenseert. Leap status hoort Normal te zijn. Als er Not synchronised staat en Reference ID is 00000000 (), dan heeft chrony nog geen bron geselecteerd.

chronyc sources -v print een legenda boven de lijst, 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 geeft over de service in plaats van de status te tonen, dan is timesyncd niet de actieve daemon op deze machine, wat op zichzelf al het antwoord op uw vraag is.

Voor een ruwe controle tegen de buitenwereld zonder extra tools, vergelijkt u uw klok met een publieke HTTP Date-header, die in GMT wordt geserveerd 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 in uw configuratie.

chrony of systemd-timesyncd op een VPS

Ubuntu en Debian leveren standaard systemd-timesyncd mee. Dit is een SNTP-client (Simple Network Time Protocol): het bevraagt één server tegelijk en corrigeert de klok in de richting van die server. Voor een machine die online blijft en ongeveer op tijd start, is dit voldoende en het verbruikt vrijwel geen resources.

chrony is een volledige NTP-implementatie en de betere standaard 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 afzonderlijk na te jagen. Het herstelt ook snel van twee situaties die een VM wel meemaakt, 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, dus apt verwijdert timesyncd zodra chrony wordt geïnstalleerd. Dit is correct en gewenst. Draai nooit beide tegelijk, omdat twee daemons die dezelfde klok instellen met elkaar zullen conflicteren; de gerapporteerde offset van beide 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 geschikt 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 tijdbronnen. 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 klok alleen nog geleidelijk bijgesteld (slewing).

Als u wilt dat het tijdverkeer wordt geverifieerd tegen manipulatie onderweg, ondersteunen chrony 4 en later NTS (Network Time Security). Controleer eerst uw versie met chronyd -v en houd er rekening mee dat NTS vereist dat zowel de uitgaande TCP-poort 4460 als UDP 123 openstaan:

server time.cloudflare.com iburst nts

Herstart en verifieer de configuratie voordat u deze 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 weggewerkt; 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 zwaar ontregelde klok langdurig afwijkend kan blijven. chrony voert alleen een step uit binnen het venster dat makestep toestaat; standaard is dit alleen tijdens de eerste paar updates na het starten van de daemon. Een chronyd die al een week draait en vervolgens een afwijking van veertig seconden detecteert, zal deze via slewing corrigeren, en slewing van veertig seconden duurt veel langer dan u wilt wachten. Forceer dit eenmalig, 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 na voordat u dit uitvoert op een drukke databasehost, omdat een klok die achteruit springt software kan verwarren 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 binnen een unprivileged container mislukt met date: cannot set date: Operation not permitted, aangezien de kernel CAP_SYS_TIME vereist voor die aanroep. Het toekennen 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 binnen een container is geen klokprobleem. Een image die zijn eigen /etc/localtime bevat, 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 twee keer uitgevoerd op de dag dat de klok wordt teruggezet, en wordt helemaal niet uitgevoerd op de dag dat de klok wordt vooruitgezet. 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 binnen 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 niet over na zou moeten hoeven denken om 03:00 uur. 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 draaien, is de redenen waarom een cron-taak 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 rekenoefening, en conversies die onder druk worden uitgevoerd leiden ertoe dat mensen een tijdlijn verkeerd interpreteren. Houd systemen op UTC, sla tijdstempels op in UTC en converteer pas op het moment dat een mens ze leest. Iedereen die een lokale weergave wil voor één commando, kan daarom vragen zonder de machine te verplaatsen:

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 hiervan 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.

Probleemoplossing per symptoom

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 dus 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 geweigerde sleutel, die een eigen melding geeft en wordt behandeld in de handleiding voor fouten bij publickey-authenticatie.

apt update meldt dat een Release-bestand nog niet geldig is. Het volledige bericht noemt de repository en hoe lang 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 stond goed, maar is versprongen. 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 bij het opstarten wordt gestart 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 de timer-interrupt moet plaatsvinden, krijgt vertraagde samples, waardoor de offset gaat zwerven in plaats van convergeren. top toont dit als het st-cijfer op de CPU-regel. CPU-steal time lezen 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 soortgelijke 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 machine is met de onjuiste klok, 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 menselijk geheugen. Het uitlezen van timedatectl en chronyc tracking kost samen slechts twee seconden. Voer deze uit als onderdeel van de eerste tien minuten op een nieuwe VPS, en herhaal dit wanneer u de reguliere checklist voor Linux-serveronderhoud doorloopt. Als u liever wilt dat de controle automatisch wordt uitgevoerd en een melding geeft zodra de afwijking toeneemt, beschrijft het schrijven van een systemd service en timer het patroon voor een kleine unit die volgens een schema rapporteert.

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 eigen vlag van de kernel, ingesteld door de daemon die de klok beheert; yes in combinatie met NTP service: n/a is daarom normaal en gezond op een machine met chrony. Voor de grootte van de afwijking voert u chronyc tracking uit en leest u System time, of u voert timedatectl timesync-status uit en leest 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 van belang 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 accuraat is. 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 voort uit een teller die elke 30 seconden verspringt; de server en uw telefoon moeten het dus eens zijn over de huidige stap. De meeste verificatiemethoden 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 toont, herstel dan de synchronisatie en de codes zullen weer overeenkomen zonder dat het gedeelde geheim hoeft te worden aangepast.

Kan ik de tijd instellen in 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 stelt de container in staat om de klok van de host aan te passen in plaats van een eigen klok te krijgen. Synchroniseer de host. Een afwijkende lokale tijd in 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 de 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 weergave wenst, kan een commando vooraf laten gaan door bijvoorbeeld TZ=America/New_York date, wat niets verandert aan de systeemklok.