Tijdzone en tijdsynchronisatie instellen op een Linux-server

Naar de klok van een server kijkt niemand, zolang die klopt. Loopt hij verkeerd, dan meldt de klok zichzelf nooit. Wat zich wel meldt, is een geweigerd certificaat, een pakketbron die apt niet accepteert, een cronjob op het verkeerde uur en een logbestand dat met geen enkel ander logbestand meer te vergelijken is.

Dit artikel gaat dieper in op stap 5 van de checklist voor een nieuwe rootserver. Wie daar de twee commando's heeft afgewerkt, heeft aan de plicht voldaan. Hier gaat het om alles wat daar nog bovenop komt: de keuze van de tijddienst, de hardwareklok, UTC tegenover lokale tijd, het bewijs dat de synchronisatie loopt en de foutmeldingen die daarbij horen.

Alle gegevens hebben betrekking op Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. De commando's zijn geschreven voor gebruik als root. Werkt u als gewone gebruiker, zet dan sudo voor elk commando.

Wat een verkeerde klok werkelijk stukmaakt

De gemene deler: geen van deze meldingen heeft het over de klok.

• TLS-certificaten. Elk certificaat heeft een geldigheidsvenster. Ligt de systeemtijd daarvóór, dan meldt curl curl: (60) SSL certificate problem: certificate is not yet valid, ligt hij erna, dan certificate has expired. Elke uitgaande aanroep krijgt daarmee te maken.
• apt. Release-bestanden dragen een uitgiftedatum en een vervaldatum. Loopt de klok achter, dan komt Release file for ... is not valid yet, loopt hij duidelijk voor, dan navenant is expired. De server krijgt dan geen beveiligingsupdates meer, zonder dat er ook maar één dienst uitvalt.
• De logs. Twee machines die vijf minuten uit elkaar lopen, zijn niet meer naast elkaar te leggen, en juist dan hebt u dat nodig: bij een inbraak of bij een storing.
• Cronjobs en systemd-timers. cron rekent in de systeemtijdzone. Wie de zone later omzet, verschuift elke job. Springt de klok, dan draaien jobs dubbel of helemaal niet. Uitgebreid behandeld in Cronjob onder Linux instellen.
• Back-ups. Bijna elke back-up noemt zijn mappen naar de datum en verwijdert op leeftijd. Een klok die een dag terugspringt, overschrijft de back-up van gisteren.
• Tijdgebonden eenmalige wachtwoorden. TOTP rekent in vensters van 30 seconden, meestal met een tolerantie van één venster aan elke kant. Wijkt de serverklok verder af, dan wordt elke correcte code geweigerd. Dat is het enige punt op deze lijst dat u werkelijk buitensluit.

Voordat u iets wijzigt: de weg terug en de inventarisatie

De weg terug

Een wijziging van de tijdzone verbreekt geen lopende SSH-sessie, en de synchronisatie inschakelen is net zo onschuldig. Twee dingen in dit artikel zijn dat niet: een klok die een grote sprong maakt, en het wisselen van tijddienst. Een grote sprong naar achteren maakt geldige certificaten tijdelijk ongeldig en gooit TOTP-logins uit hun venster. Het wisselen van tijddienst verwijdert de oude dienst voordat de nieuwe draait: breekt de installatie daartussen af, dan heeft de server helemaal geen tijdsynchronisatie meer, en dat valt pas dagen later op.

KVM-rootservers en dedicated servers van KernelHost hebben geen IPMI en geen iDRAC. De toegangsweg die zonder netwerkdiensten in het gastsysteem werkt, is de VNC-console in het klantenpaneel. Die hangt aan de virtualisatielaag of aan de aansluiting zelf, en heeft geen last van een verkeerde klok in de gast. Log daar vooraf één keer in en controleer of u het rootwachtwoord kent.

De huidige stand in vier commando's

Noteer wat er nu geldt. Zonder die notitie weet u later niet of een afwijking nieuw is:

timedatectl
readlink -f /etc/localtime
date -u
systemctl is-active systemd-timesyncd chrony

Van de zeven regels die timedatectl afdrukt, tellen er drie. Time zone noemt de zone met afkorting en verschuiving, bijvoorbeeld Europe/Vienna (CEST, +0200). System clock synchronized zegt of de klok ooit is gelijkgezet. NTP service kent drie toestanden die geregeld door elkaar worden gehaald:

In het derde geval levert timedatectl show -p CanNTP --value een no op, en elke poging om de synchronisatie in te schakelen eindigt met Failed to set ntp: NTP not supported.

Tijdzone en tijdsynchronisatie zijn twee verschillende dingen

De kernel houdt precies één teller bij: seconden sinds 1 januari 1970, gerekend in UTC. Die teller is de systeemtijd, en hij kent geen tijdzone, want een zone is louter een kwestie van weergave. Daaruit volgen twee dingen. De tijdzone wijzigen verschuift geen enkel moment, date -u levert ervoor en erna dezelfde uitvoer. En de klok synchroniseren verandert de teller, niet de weergave, een verkeerd ingestelde zone blijft dus verkeerd. Twee taken, twee controles.

Stap 1: de tijdzone instellen

Zonenamen komen uit de IANA-database en luiden bijna altijd Continent/Stad, in Engelse schrijfwijze. Zoek de naam op in plaats van hem te raden:

timedatectl list-timezones | grep -i vienna
timedatectl set-timezone Europe/Vienna

Controle:

timedatectl show -p Timezone --value
readlink -f /etc/localtime
date +%Z

Verwacht worden Europe/Vienna, het pad /usr/share/zoneinfo/Europe/Vienna en een afkorting die bij het seizoen past, in de zomer CEST en in de winter CET.

Drie valkuilen

Het bestand /etc/timezone is niet doorslaggevend. Debian 13 levert het niet meer mee, daar eindigt een cat /etc/timezone met No such file or directory, en ook tzdata brengt het niet terug. Op de andere drie systemen bestaat het nog, maar overal is alleen de symlink /etc/localtime bepalend.

Zonder tzdata zijn er geen zones. Op minimale images, en vooral bij Ubuntu, ontbreekt de zonedatabase. Dan mislukt zelfs een correct gespelde naam met Failed to set time zone: Invalid or not installed time zone 'Europe/Vienna', en geeft timedatectl list-timezones maar één regel terug. Na de reparatie moeten dat er enkele honderden zijn:

DEBIAN_FRONTEND=noninteractive apt-get install -y tzdata
timedatectl list-timezones | wc -l

Draaiende diensten onthouden de oude zone. cron, databases en applicatieservers lezen de tijdzone bij de start en loggen na een omzetting gewoon verder in de oude zone, totdat ze opnieuw worden gestart.

In omgevingen zonder draaiende systemd bestaat timedatectl niet. De klassieke weg leidt tot hetzelfde resultaat:

ln -sf /usr/share/zoneinfo/Europe/Vienna /etc/localtime
dpkg-reconfigure -f noninteractive tzdata
readlink -f /etc/localtime

UTC of lokale tijd: een bewuste keuze

Veel beheerders laten hun servers op UTC draaien, en daar zijn goede redenen voor. UTC kent geen zomertijd, dus ook geen uur dat twee keer voorkomt en geen uur dat ontbreekt: in de nacht van de omschakeling bestaat 02:30 lokale tijd in het najaar dubbel en in het voorjaar helemaal niet, wat elke job in dat venster raakt. Daartegenover staat dat mensen de logs lezen en dat een onderhoudsvenster "zondag 03:00" de lokale tijd bedoelt. De bruikbare regel: wie meerdere servers of locaties beheert, kiest UTC, wie één enkele server op de kantoorklok laat lopen, kiest de lokale tijd. Fout is alleen: het niet weten.

timedatectl set-timezone Etc/UTC

Voor één enkele blik hoeft u de systeemtijdzone niet aan te raken, de variabele TZ volstaat en werkt alleen op die ene aanroep:

TZ=Europe/Vienna date
TZ=Europe/Vienna journalctl -u nginx --since "today"

Stap 2: de tijddienst kiezen

Voor Debian en Ubuntu staan drie kandidaten klaar die dezelfde taak oplossen, maar met een heel verschillende omvang.

Alle drie melden het pakketsysteem dezelfde rol: Provides: time-daemon en tegelijk Conflicts: time-daemon. Wie er twee in één commando opvraagt, krijgt nul op het rekest:

The following packages have unmet dependencies:
 chrony : Conflicts: time-daemon
 systemd-timesyncd : Conflicts: time-daemon
E: Unable to correct problems, you have held broken packages.

Wie chrony installeert terwijl timesyncd draait, moet de regel The following packages will be REMOVED: systemd-timesyncd niet over het hoofd zien. Dat is de bedoeling, want twee processen aan dezelfde klok zijn erger dan geen enkel proces. Controleer daarna meteen of de nieuwe dienst draait.

Twee pakketnamen uit oudere handleidingen zijn afgedaan: ntp en ntpdate. Op Debian 12 en op beide Ubuntu-versies zijn het nog slechts overgangspakketten naar ntpsec, op Debian 13 meldt apt-cache policy ntp eenvoudigweg Candidate: (none).

Variant A: systemd-timesyncd

Het pakket systemd beveelt op alle vier de systemen systemd-timesyncd | time-daemon aan. Een normale installatie brengt de dienst dus mee, een minimale image zonder aanbevolen pakketten niet.

DEBIAN_FRONTEND=noninteractive apt-get install -y systemd-timesyncd
systemctl enable --now systemd-timesyncd

De meegeleverde /etc/systemd/timesyncd.conf bevat uitsluitend uitgecommentarieerde standaardwaarden. Eigen waarden horen thuis in een aanvullingsbestand, waarvan de map standaard niet bestaat:

mkdir -p /etc/systemd/timesyncd.conf.d
cat > /etc/systemd/timesyncd.conf.d/10-kernelhost.conf <<'EOF'
[Time]
NTP=0.at.pool.ntp.org 1.at.pool.ntp.org 2.at.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org
EOF
systemctl restart systemd-timesyncd

Onder NTP= staan de servers die worden bevraagd. FallbackNTP= treedt alleen in werking als geen van die servers antwoordt, standaard staat daar op Debian de Debian-pool en op Ubuntu ntp.ubuntu.com.

Controle:

systemd-analyze cat-config systemd/timesyncd.conf
systemctl is-active systemd-timesyncd
timedatectl timesync-status

Het eerste commando toont de samengestelde configuratie, en uw aanvullingsbestand moet daarin met het volledige pad opduiken. Het derde noemt de gebruikte server, het aanvraaginterval en de laatst gemeten afwijking. Antwoordt het in plaats daarvan met Failed to query server: Connection timed out, dan draait timesyncd niet. Op die melding wacht u 25 seconden.

Variant B: chrony

apt-get install -y chrony
systemctl enable --now chrony

De unit heet op alle vier de distributies chrony.service en draagt daarnaast de aliasnaam chronyd.service. De meegeleverde /etc/chrony/chrony.conf is al bruikbaar ingevuld: Debian bevraagt pool 2.debian.pool.ntp.org iburst, Ubuntu bevraagt ntp.ubuntu.com plus drie regels uit de Ubuntu-pool. Wijzig dat bestand niet. Het neemt via confdir /etc/chrony/conf.d een map op die pakketupdates ongemoeid laten:

cat > /etc/chrony/conf.d/10-kernelhost.conf <<'EOF'
pool 0.at.pool.ntp.org iburst
EOF
systemctl restart chrony

Controle met chronyc tracking, zo ziet dat eruit op een netjes draaiende server:

Reference ID    : A29FC801 (time.cloudflare.com)
Stratum         : 4
Ref time (UTC)  : Thu Sep 03 17:53:29 2026
System time     : 0.000135970 seconds fast of NTP time
Last offset     : +0.000042723 seconds
RMS offset      : 0.000086483 seconds
Frequency       : 13.967 ppm fast
Residual freq   : +0.002 ppm
Skew            : 0.073 ppm
Root delay      : 0.008282715 seconds
Root dispersion : 0.000613841 seconds
Update interval : 1038.4 seconds
Leap status     : Normal

In de praktijk volstaan drie regels. System time is de actuele afwijking, hier ongeveer 136 microseconden. Leap status moet Normal luiden, staat er Not synchronised, dan heeft chrony nog geen bruikbare bron. Stratum zegt hoe ver u van een referentieklok verwijderd bent, 2 tot 4 is normaal. De tweede blik geldt de bronnen zelf, met chronyc -n sources:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^- 217.175.198.239               3  10   377   748   +114us[ +153us] +/-   19ms
^- 46.102.157.67                 2  10   377   558   +151us[ +192us] +/-   28ms
^* 162.159.200.1                 3  10   377   335   -251us[ -208us] +/- 4463us
^+ 152.53.132.244                2   9   377   231   +335us[ +335us] +/- 5626us

De twee tekens helemaal links vormen de eigenlijke bevinding. ^* markeert de bron waarnaar de klok wordt gezet, ^+ een bron die meetelt, ^- een bron die niet wordt gecombineerd, ^? een onbereikbare en ^x een tegenstrijdige. In de kolom Reach staat een octale waarde over de laatste acht opvragingen: 377 betekent dat alle acht zijn beantwoord, 0 betekent dat er geen enkele is aangekomen.

Vanaf versie 4 beheerst chrony Network Time Security, oftewel geauthenticeerde tijd via TLS. Dat vereist twee dingen die snel over het hoofd worden gezien: het pakket ca-certificates en een uitgaande TCP-poort 4460. Ontbreken de rootcertificaten, dan mislukt de afstemming met Error in the certificate verification. The certificate is NOT trusted. The certificate issuer is unknown.

apt-get install -y ca-certificates
cat > /etc/chrony/conf.d/20-nts.conf <<'EOF'
server time.cloudflare.com iburst nts
EOF
systemctl restart chrony
chronyc authdata

De hardwareklok

Naast de systeemtijd bestaat er een tweede klok: de hardwareklok, kortweg RTC. Die levert bij de start de eerste tijdwaarde, lang voordat er een tijddienst draait. Op een KVM-rootserver is dat de klok die de virtualisatielaag aanbiedt, in timedatectl staat hij op de regel RTC time. Belangrijk is precies één instelling, de laatste regel van de uitvoer:

timedatectl set-local-rtc 0
timedatectl | grep "RTC in local TZ"

Staat daar yes, dan wordt de hardwareklok als lokale tijd gelezen. Dat is een concessie aan computers die daarnaast Windows starten, en op een server is het zinloos. De schade laat zich twee keer per jaar zien: bij de omschakeling is een als lokale tijd gevoerde hardwareklok een uur lang niet eenduidig, en een herstart in dat venster kan de server opstarten met een tijd die er een uur naast zit.

In de andere richting geldt: chrony schrijft de gecorrigeerde tijd via de standaardinstelling rtcsync regelmatig terug naar de hardwareklok, en die regel staat in de meegeleverde chrony.conf van alle vier de distributies. systemd-timesyncd kent zo'n optie niet. Met de hand gaat het met hwclock --systohc. Dat commando komt op Debian 12, Debian 13 en Ubuntu 24.04 uit het pakket util-linux-extra; meldt de shell hwclock: command not found, installeer dat pakket dan alsnog. Op Ubuntu 22.04 hoort het bij util-linux.

Stap 3: aantonen dat de synchronisatie loopt

Dat een commando zonder fout is doorgelopen, is geen bewijs. Deze vijf controles samen zijn dat wel:

1. De algemene toestand. timedatectl toont System clock synchronized: yes en NTP service: active. Beide regels samen, niet één ervan.
2. De dienst zelf. systemctl is-enabled chrony en systemctl is-active chrony antwoorden met enabled en active, bij timesyncd op dezelfde manier. enabled alleen betekent enkel dat hij bij de volgende start zou draaien.
3. Er wordt werkelijk een bron bereikt. Bij chrony moet in chronyc -n sources ten minste één regel met ^* staan en moet de kolom Reach van 0 af zijn. Bij timesyncd noemt timedatectl timesync-status een concrete server.
4. De afwijking is klein. chronyc tracking hoort bij System time micro- of milliseconden te tonen. Hele seconden betekenen dat de correctie nog loopt of dat er iets vastzit.
5. Het overleeft een herstart. Start de server één keer opnieuw op en herhaal controle 1 tot en met 4. Dat is de enige controle die de vraag definitief beantwoordt.

De regel die u niet op zichzelf mag vertrouwen: System clock synchronized: yes weerspiegelt een vlag in de kernel die is gezet door het proces dat de klok als laatste heeft gelijkgezet. Die vlag verdwijnt niet wanneer de tijddienst crasht. Een server kan deze regel dus tonen en toch al uren zonder afstemming draaien.

Diensten die bij de start dwingend een juiste klok nodig hebben, zet u met After=time-sync.target op de juiste plek in de volgorde. Opdat dat doel pas na de afstemming wordt bereikt, is er daarnaast een wachtende unit nodig: systemd-time-wait-sync.service bij timesyncd, chrony-wait.service bij chrony. Die laatste leveren Debian 12, Debian 13 en Ubuntu 24.04 mee, Ubuntu 22.04 niet. Hoe een eigen unit is opgebouwd, leest u in systemd-service aanmaken.

Firewall en netwerk

NTP gaat naar buiten via UDP-poort 123, voor NTS komt TCP 4460 erbij. In de standaardinstelling van UFW is uitgaand verkeer toegestaan, er valt dus niets te doen. Wie ufw default deny outgoing heeft ingesteld, moet de poort vrijgeven, anders blijft de klok staan zonder dat er ook maar één dienst een foutmelding schrijft:

ufw allow out 123/udp comment 'NTP'

De rest over de firewall staat in UFW-firewall instellen. In de tegenovergestelde richting geldt: een tijddienst die aanvragen uit het internet beantwoordt, is een versterker voor reflectieaanvallen. chrony en systemd-timesyncd antwoorden standaard niemand, pas een allow-regel in de chrony-configuratie maakt van de client een server. Zet die uitsluitend afgebakend op uw eigen netwerk. De voorgeschakelde filtering in het maincubes-datacenter in Frankfurt am Main vangt zulk verkeer af, maar de beste versterker blijft nog altijd de versterker die er helemaal niet is.

Als de klok er ver naast zit

Tijddiensten corrigeren normaal gesproken niet door te springen, maar door de klok minimaal te versnellen of af te remmen. Daarom verdwijnt een afwijking van een minuut niet binnen een seconde, en zo hoort het ook: een sprong naar achteren laat tijdstempels dubbel voorkomen.

Voor net gestarte systemen staat in de meegeleverde chrony.conf van alle vier de distributies de regel makestep 1 3: die staat een echte sprong toe bij een afwijking van meer dan een seconde, en dat alleen voor de eerste drie afstemmingen. Precies dat geval doet zich voor bij een virtuele machine die uit een image is gekloond of uit een snapshot is teruggehaald. Is dat niet genoeg, forceer dan de sprong en wacht het resultaat af:

chronyc makestep
chronyc waitsync 10

Meten zonder iets te veranderen gaat met de optie -Q: die bevraagt de geconfigureerde bronnen, meldt de afwijking en sluit af zonder de klok aan te raken. De interessante regel luidt dan bijvoorbeeld System clock wrong by 0.000363 seconds (ignored):

chronyd -Q -f /etc/chrony/chrony.conf

Wat u niet moet doen, is de klok met date -s handmatig zetten terwijl er een tijddienst draait. timedatectl set-time weigert dat uitdrukkelijk met Failed to set time: Automatic time synchronization is enabled, omdat er anders twee instanties tegelijk aan dezelfde klok zouden draaien.

Veelvoorkomende fouten en oplossingen

Failed to set time zone: Invalid or not installed time zone 'Europe/Wien': de zonenaam bestaat niet. De IANA-database hanteert Engelse stadsnamen, het heet dus Europe/Vienna, Europe/Zurich en Europe/Prague. Komt dezelfde melding bij een correct gespelde naam, dan ontbreekt de zonedatabase: de tegenproef is timedatectl list-timezones | wc -l, en blijft er één enkele regel over, installeer dan tzdata alsnog.

Failed to set ntp: NTP not supported: er is helemaal geen tijddienst geïnstalleerd, timedatectl show -p CanNTP --value levert dan no op. De optie set-ntp stuurt alleen diensten aan die zich onder /usr/lib/systemd/ntp-units.d/ hebben ingeschreven: timesyncd met 80-systemd-timesync.list, chrony met 50-chrony.list.

timedatectl set-ntp true loopt zonder fout door, maar NTP service blijft toch inactive: het commando meldt alleen dat het de unit opdracht heeft gegeven, niet dat die draait. De oorzaak staat in het journal, bijvoorbeeld op te vragen met journalctl -u systemd-timesyncd -n 20.

506 Cannot talk to daemon: chronyc bereikt de dienst niet, omdat chronyd niet draait. systemctl status chrony noemt de reden. De melding luidt bij elk subcommando van chronyc hetzelfde.

chrony.service - chrony, an NTP client/server was skipped because of an unmet condition check (ConditionCapability=CAP_SYS_TIME).: het systeem mag de klok helemaal niet zetten. Bij een VPS op containerbasis (LXC, OpenVZ) is dat het normale geval, daar geeft het hostsysteem de tijd op. Op een KVM-rootserver mag de gast zijn klok zelf zetten, daar is de melding een echte bevinding. Vanuit timesyncd gezien ziet hetzelfde geval er zo uit: systemd-timesyncd.service - Network Time Synchronization was skipped because of an unmet condition check (ConditionVirtualization=!container).

Release file for ... is not valid yet bij apt update: de klok loopt achter. Zet eerst de tijd goed en herhaal daarna apt update. Omgekeerd wijst is expired op een voorlopende klok, en zeldzamer op een verouderde spiegelserver.

Failed to query server: Connection timed out bij timedatectl timesync-status: timesyncd draait niet, of chrony heeft het vervangen. Is chrony de actieve dienst, dan blijft dit commando permanent zonder antwoord, en dat is geen fout. Het juiste gereedschap heet dan chronyc tracking.

Distributieverschillen in één oogopslag

Overal hetzelfde is daarentegen: de tijdzone hangt alleen aan de symlink /etc/localtime, en de ene tijddienst sluit elke andere uit.

De korte versie

Voor een pas opgeleverde rootserver die op lokale tijd moet draaien en met de standaarddienst toekomt:

DEBIAN_FRONTEND=noninteractive apt-get install -y systemd-timesyncd tzdata
timedatectl set-timezone Europe/Vienna
timedatectl set-local-rtc 0
systemctl enable --now systemd-timesyncd
timedatectl

Aan het eind verwacht u Time zone: Europe/Vienna, System clock synchronized: yes, NTP service: active en RTC in local TZ: no. Staan die vier regels er ook na een herstart zo bij, dan is de klok van deze server afgehandeld.