Konfiguracja strefy czasowej i synchronizacji czasu na serwerze Linux

Zegara serwera nikt nie zauważa, dopóki chodzi dobrze. Gdy zacznie chodzić źle, nigdy nie odzywa się sam zegar, tylko odrzucony certyfikat, źródło pakietów, którego apt nie przyjmuje, cronjob o złej godzinie i plik logu, którego nie da się już zestawić z żadnym innym.

Ten artykuł rozwija krok 5 z listy kontrolnej dla nowego serwera root. Kto wykonał tam te dwa polecenia, zrobił to, co konieczne. Tutaj chodzi o wszystko ponad to: o wybór usługi czasu, zegar sprzętowy, UTC kontra czas lokalny, dowód na działającą synchronizację i towarzyszące temu komunikaty błędów.

Wszystkie informacje dotyczą Debiana 13 (trixie), Debiana 12 (bookworm), Ubuntu 24.04 LTS i Ubuntu 22.04 LTS. Polecenia są napisane pod pracę jako root. Jeśli pracujesz jako zwykły użytkownik, dopisuj przed każdym poleceniem sudo.

Co naprawdę psuje źle chodzący zegar

Wspólny mianownik: żaden z tych komunikatów nie mówi o zegarze.

• Certyfikaty TLS. Każdy certyfikat ma okno ważności. Jeśli czas systemowy wypada przed nim, curl zgłasza curl: (60) SSL certificate problem: certificate is not yet valid, jeśli za nim, certificate has expired. Dotyczy to każdego wywołania na zewnątrz.
• apt. Pliki Release mają datę wystawienia i datę wygaśnięcia. Gdy zegar się spóźnia, pojawia się Release file for ... is not valid yet, gdy wyraźnie się spieszy, odpowiednio is expired. Serwer przestaje wtedy dostawać aktualizacje bezpieczeństwa, choć żadna usługa nie przestaje działać.
• Logi. Dwóch maszyn rozjechanych o pięć minut nie da się już zestawić ze sobą, a potrzebujesz tego dokładnie wtedy: przy włamaniu albo przy awarii.
• Cronjoby i timery systemd. cron liczy w systemowej strefie czasowej. Kto przestawi strefę później, przesuwa każde zadanie. Gdy zegar skacze, zadania wykonują się podwójnie albo wcale. Szczegółowo w artykule konfiguracja cronjoba.
• Backupy. Prawie każdy backup nazywa swoje katalogi datą i kasuje według wieku. Zegar, który cofnie się o jeden dzień, nadpisze wczorajszy backup.
• Hasła jednorazowe oparte na czasie. TOTP liczy w oknach 30-sekundowych, z tolerancją najczęściej jednego okna w każdą stronę. Jeśli zegar serwera odbiega bardziej, każdy poprawny kod zostanie odrzucony. To jedyny punkt z tej listy, który naprawdę zamyka ci drzwi.

Zanim cokolwiek zmienisz: droga odwrotu i inwentaryzacja

Droga odwrotu

Zmiana strefy czasowej nie zrywa działającej sesji SSH, a włączenie synchronizacji jest równie nieszkodliwe. Dwie rzeczy w tym artykule takie nie są: zegar, który skacze daleko, oraz zmiana usługi czasu. Duży skok wstecz unieważnia na jakiś czas ważne certyfikaty i wyrzuca logowania TOTP poza okno tolerancji. Zmiana usługi czasu usuwa starą, zanim ruszy nowa: jeśli instalacja przerwie się w międzyczasie, serwer nie ma już żadnej synchronizacji czasu, a zauważysz to dopiero po kilku dniach.

Serwery root KVM i serwery dedykowane KernelHosta nie mają IPMI ani iDRAC. Dostępem, który działa bez usług sieciowych w systemie gościa, jest konsola VNC w panelu klienta. Jest ona podpięta do warstwy wirtualizacji albo do samego łącza, więc błędny zegar w systemie gościa jej nie dotyczy. Zaloguj się tam raz zawczasu i sprawdź, czy znasz hasło root.

Stan faktyczny w czterech poleceniach

Zanotuj, co obowiązuje teraz. Bez tej notatki nie będziesz później wiedzieć, czy odchylenie jest nowe:

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

Z siedmiu wierszy polecenia timedatectl liczą się trzy. Time zone podaje strefę razem ze skrótem i przesunięciem, na przykład Europe/Vienna (CEST, +0200). System clock synchronized mówi, czy zegar kiedykolwiek został zsynchronizowany. NTP service ma trzy stany, które regularnie się myli:

W trzecim przypadku timedatectl show -p CanNTP --value zwraca no, a każda próba włączenia synchronizacji kończy się komunikatem Failed to set ntp: NTP not supported.

Strefa czasowa i synchronizacja czasu to dwie różne rzeczy

Kernel prowadzi dokładnie jeden licznik: sekundy od 1 stycznia 1970 roku, liczone w UTC. Ten licznik to czas systemowy i nie zna żadnej strefy czasowej, bo strefa jest wyłącznie kwestią prezentacji. Wynikają z tego dwie rzeczy. Zmiana strefy czasowej nie przesuwa ani jednej chwili, date -u zwraca przed nią i po niej dokładnie to samo. A synchronizacja zegara zmienia licznik, nie prezentację, więc źle ustawiona strefa pozostaje błędna. Dwa zadania, dwie kontrole.

Krok 1: ustawienie strefy czasowej

Nazwy stref pochodzą z bazy IANA i prawie zawsze mają postać Kontynent/Miasto, w angielskiej pisowni. Wyszukaj nazwę, zamiast ją zgadywać:

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

Kontrola skuteczności:

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

Spodziewane są Europe/Vienna, ścieżka /usr/share/zoneinfo/Europe/Vienna oraz skrót pasujący do pory roku, latem CEST, a zimą CET.

Trzy pułapki

Plik /etc/timezone nie jest miarodajny. Debian 13 już go nie dostarcza, tam cat /etc/timezone kończy się komunikatem No such file or directory, i nawet tzdata go nie przywraca. W pozostałych trzech systemach jeszcze istnieje, ale wszędzie decyduje wyłącznie dowiązanie symboliczne /etc/localtime.

Bez tzdata nie ma stref. W odchudzonych obrazach, szczególnie w przypadku Ubuntu, brakuje bazy stref. Wtedy nawet poprawnie zapisana nazwa kończy się błędem Failed to set time zone: Invalid or not installed time zone 'Europe/Vienna', a timedatectl list-timezones wypisuje tylko jeden wiersz. Po naprawie musi ich być kilkaset:

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

Działające usługi pamiętają starą strefę. cron, bazy danych i serwery aplikacji czytają strefę czasową przy starcie i po przestawieniu nadal logują w starej strefie, dopóki ich nie zrestartujesz.

W środowiskach bez działającego systemd nie ma timedatectl. Klasyczna droga prowadzi do tego samego wyniku:

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

UTC czy czas lokalny: świadoma decyzja

Wielu operatorów trzyma serwery na UTC i są ku temu dobre powody. UTC nie zna czasu letniego, a więc nie zna też godziny, która występuje dwa razy, ani takiej, której brakuje: w noc zmiany czasu godzina 02:30 czasu lokalnego jesienią istnieje podwójnie, a wiosną wcale, co dotyczy każdego zadania w tym oknie. Z drugiej strony logi czytają ludzie, a okno serwisowe „w niedzielę o 03:00” oznacza czas lokalny. Praktyczna reguła: kto prowadzi kilka serwerów albo kilka lokalizacji, bierze UTC, kto prowadzi pojedynczy serwer według zegara w biurze, bierze czas lokalny. Błędem jest tylko tego nie wiedzieć.

timedatectl set-timezone Etc/UTC

Do jednorazowego zerknięcia nie musisz ruszać systemowej strefy czasowej, wystarczy zmienna TZ, która działa wyłącznie na to jedno wywołanie:

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

Krok 2: wybór usługi czasu

Dla Debiana i Ubuntu do wyboru są trzy programy, które rozwiązują to samo zadanie w bardzo różnym zakresie.

Wszystkie trzy zgłaszają systemowi pakietów tę samą rolę: Provides: time-daemon i jednocześnie Conflicts: time-daemon. Kto zażąda dwóch z nich w jednym poleceniu, dostanie odmowę:

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.

Kto instaluje chrony, gdy timesyncd akurat działa, nie powinien przeoczyć wiersza The following packages will be REMOVED: systemd-timesyncd. Tak ma być, bo dwa procesy przy tym samym zegarze są gorsze niż żaden. Zaraz potem sprawdź, czy nowa usługa działa.

Dwie nazwy pakietów ze starszych poradników są już nieaktualne: ntp i ntpdate. Na Debianie 12 i w obu wersjach Ubuntu to już tylko pakiety przejściowe wskazujące na ntpsec, a na Debianie 13 apt-cache policy ntp zwraca po prostu Candidate: (none).

Wariant A: systemd-timesyncd

Pakiet systemd we wszystkich czterech systemach poleca systemd-timesyncd | time-daemon. Normalna instalacja przynosi więc tę usługę ze sobą, minimalny obraz bez pakietów polecanych już nie.

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

Dostarczony plik /etc/systemd/timesyncd.conf zawiera wyłącznie zakomentowane wartości domyślne. Własne ustawienia należą do pliku uzupełniającego, którego katalog fabrycznie nie istnieje:

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

Pod NTP= stoją serwery, które będą odpytywane. FallbackNTP= wchodzi do gry tylko wtedy, gdy żaden z nich nie odpowiada, a fabrycznie stoi tam na Debianie pula Debiana, a na Ubuntu ntp.ubuntu.com.

Kontrola skuteczności:

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

Pierwsze polecenie pokazuje złożoną konfigurację, twój plik uzupełniający musi się w niej pojawić z pełną ścieżką. Trzecie podaje używany serwer, interwał odpytywania i ostatnio zmierzone odchylenie. Jeśli zamiast tego odpowiada Failed to query server: Connection timed out, timesyncd nie działa. Na ten komunikat czeka się 25 sekund.

Wariant B: chrony

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

Jednostka we wszystkich czterech dystrybucjach nazywa się chrony.service i ma dodatkowo alias chronyd.service. Dostarczony plik /etc/chrony/chrony.conf jest już sensownie wypełniony: Debian odpytuje pool 2.debian.pool.ntp.org iburst, Ubuntu odpytuje ntp.ubuntu.com plus trzy wpisy z puli Ubuntu. Nie zmieniaj tego pliku. Przez confdir /etc/chrony/conf.d dołącza on katalog, którego aktualizacje pakietów nie ruszają:

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

Kontrola skuteczności poleceniem chronyc tracking, tak to wygląda na czysto działającym serwerze:

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

Na co dzień wystarczą trzy wiersze. System time to bieżące odchylenie, tutaj około 136 mikrosekund. Leap status musi mieć wartość Normal, przy Not synchronised chrony nie ma jeszcze użytecznego źródła. Stratum mówi, jak daleko jesteś od zegara referencyjnego, od 2 do 4 to wartość normalna. Drugie spojrzenie należy się samym źródłom, poleceniem 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

Właściwa diagnoza kryje się w dwóch znakach po lewej stronie. ^* oznacza źródło, według którego ustawiany jest zegar, ^+ takie, które współtworzy wynik, ^- takie, które nie jest łączone, ^? nieosiągalne, a ^x sprzeczne. W kolumnie Reach stoi wartość ósemkowa z ostatnich ośmiu odpytań: 377 znaczy, że odpowiedziano na wszystkie osiem, 0 znaczy, że nie dotarła żadna.

Od wersji 4 chrony obsługuje Network Time Security, czyli uwierzytelniony czas przez TLS. Wymaga to dwóch łatwych do przeoczenia rzeczy: pakietu ca-certificates oraz wychodzącego portu TCP 4460. Gdy brakuje certyfikatów głównych, synchronizacja kończy się błędem 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

Zegar sprzętowy

Obok czasu systemowego istnieje drugi zegar: zegar sprzętowy, w skrócie RTC. To on przy starcie dostarcza pierwszą wartość czasu, na długo zanim ruszy jakakolwiek usługa czasu. Na serwerze root KVM jest to zegar udostępniany przez warstwę wirtualizacji, w timedatectl znajdziesz go w wierszu RTC time. Ważne jest dokładnie jedno ustawienie, ostatni wiersz wyjścia:

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

Jeśli stoi tam yes, zegar sprzętowy jest odczytywany jako czas lokalny. To ustępstwo wobec komputerów, które równolegle uruchamiają Windows, a na serwerze nie ma ono żadnego sensu. Szkoda ujawnia się dwa razy w roku: przy zmianie czasu zegar sprzętowy prowadzony jako czas lokalny przez godzinę nie jest jednoznaczny, a restart w tym oknie może podnieść serwer z czasem błędnym o godzinę.

W drugą stronę jest tak: chrony dzięki domyślnemu ustawieniu rtcsync regularnie zapisuje skorygowany czas z powrotem do zegara sprzętowego, a ten wiersz stoi w dostarczonym pliku chrony.conf wszystkich czterech dystrybucji. systemd-timesyncd nie zna takiej opcji. Ręcznie zrobisz to poleceniem hwclock --systohc. Na Debianie 12, Debianie 13 i Ubuntu 24.04 polecenie pochodzi z pakietu util-linux-extra; jeśli powłoka zgłasza hwclock: command not found, doinstaluj go. Na Ubuntu 22.04 należy do util-linux.

Krok 3: udowodnij, że synchronizacja działa

To, że polecenie wykonało się bez błędu, nie jest jeszcze dowodem. Tych pięć kontroli nim jest:

1. Stan ogólny. timedatectl pokazuje System clock synchronized: yes oraz NTP service: active. Oba wiersze razem, nie jeden z nich.
2. Sama usługa. systemctl is-enabled chrony i systemctl is-active chrony odpowiadają enabled oraz active, przy timesyncd odpowiednio. Samo enabled znaczy tylko tyle, że usługa ruszyłaby przy następnym starcie.
3. Jakieś źródło jest naprawdę osiągane. Przy chrony w chronyc -n sources musi stać co najmniej jeden wiersz ze znakiem ^*, a kolumna Reach musi być różna od 0. Przy timesyncd timedatectl timesync-status podaje konkretny serwer.
4. Odchylenie jest małe. chronyc tracking powinien przy System time pokazywać mikrosekundy albo milisekundy. Całe sekundy oznaczają, że korekta jeszcze trwa albo że coś się zacięło.
5. Wszystko przeżywa restart. Zrestartuj serwer raz i powtórz kontrole od 1 do 4. To jedyna kontrola, która odpowiada na to pytanie ostatecznie.

Wiersz, któremu nie wolno ufać w pojedynkę: System clock synchronized: yes odzwierciedla flagę w kernelu, ustawioną przez ten proces, który jako ostatni ustawił zegar. Flaga nie znika, gdy usługa czasu się wysypie. Serwer może więc pokazywać ten wiersz i mimo to od godzin działać bez synchronizacji.

Usługi, które przy starcie koniecznie potrzebują poprawnego zegara, uszereguj przez After=time-sync.target. Żeby ten cel został osiągnięty dopiero po synchronizacji, potrzebna jest dodatkowo jednostka czekająca: systemd-time-wait-sync.service przy timesyncd, chrony-wait.service przy chrony. Tę drugą dostarczają Debian 12, Debian 13 i Ubuntu 24.04, Ubuntu 22.04 już nie. Jak zbudowana jest własna jednostka, opisuje artykuł tworzenie własnej usługi systemd.

Firewall i sieć

NTP wychodzi na zewnątrz przez port UDP 123, przy NTS dochodzi do tego TCP 4460. W domyślnym ustawieniu UFW ruch wychodzący jest dozwolony, nie ma więc nic do zrobienia. Kto ustawił ufw default deny outgoing, musi otworzyć ten port, inaczej zegar stanie, a żadna usługa nie zapisze komunikatu błędu:

ufw allow out 123/udp comment 'NTP'

Resztę o firewallu znajdziesz w artykule konfiguracja firewalla UFW. W drugą stronę obowiązuje zasada: usługa czasu, która odpowiada na zapytania z internetu, jest wzmacniaczem dla ataków odbiciowych. chrony i systemd-timesyncd fabrycznie nie odpowiadają nikomu, dopiero wiersz allow w konfiguracji chrony robi z klienta serwer. Ustawiaj go wyłącznie z ograniczeniem do własnej sieci. Filtrowanie na wejściu do centrum danych maincubes we Frankfurcie nad Menem wyłapuje taki ruch, ale najlepszym wzmacniaczem pozostaje ten, którego w ogóle nie ma.

Gdy zegar jest mocno rozjechany

Usługi czasu w normalnym trybie nie korygują skokiem, tylko minimalnym przyspieszaniem albo zwalnianiem zegara. Dlatego odchylenie rzędu minuty nie znika w sekundę, i tak właśnie ma być: skok wstecz sprawia, że znaczniki czasu pojawiają się dwa razy.

Dla świeżo uruchomionych systemów w dostarczonym pliku chrony.conf wszystkich czterech dystrybucji stoi wiersz makestep 1 3: pozwala on na prawdziwy skok przy odchyleniu powyżej jednej sekundy, i to tylko przy pierwszych trzech synchronizacjach. Dokładnie taki przypadek zachodzi przy maszynie wirtualnej sklonowanej z obrazu albo przywróconej ze snapshotu. Jeśli to nie wystarcza, wymuś skok i poczekaj na wynik:

chronyc makestep
chronyc waitsync 10

Pomiar bez zmieniania czegokolwiek umożliwia przełącznik -Q: odpytuje skonfigurowane źródła, zgłasza odchylenie i kończy działanie, nie ruszając zegara. Interesujący wiersz brzmi wtedy mniej więcej System clock wrong by 0.000363 seconds (ignored):

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

Nie powinieneś natomiast ustawiać zegara ręcznie przez date -s, gdy działa usługa czasu. timedatectl set-time wprost tego odmawia komunikatem Failed to set time: Automatic time synchronization is enabled, bo inaczej dwie instancje kręciłyby jednocześnie tym samym zegarem.

Typowe błędy i ich rozwiązania

Failed to set time zone: Invalid or not installed time zone 'Europe/Wien': taka nazwa strefy nie istnieje. Baza IANA prowadzi angielskie nazwy miast, jest więc Europe/Vienna, Europe/Zurich i Europe/Prague. Jeśli ten sam komunikat pojawia się przy poprawnie zapisanej nazwie, brakuje bazy stref: kontrolą jest timedatectl list-timezones | wc -l, a gdy zostaje jeden jedyny wiersz, doinstaluj tzdata.

Failed to set ntp: NTP not supported: nie ma zainstalowanej żadnej usługi czasu, timedatectl show -p CanNTP --value zwraca wtedy no. Przełącznik set-ntp steruje wyłącznie usługami, które zarejestrowały się w /usr/lib/systemd/ntp-units.d/: timesyncd przez 80-systemd-timesync.list, chrony przez 50-chrony.list.

timedatectl set-ntp true kończy się bez błędu, a NTP service mimo to zostaje inactive: polecenie zgłasza tylko tyle, że wydało jednostce polecenie, nie że ona działa. Przyczyna stoi w dzienniku, na przykład pod journalctl -u systemd-timesyncd -n 20.

506 Cannot talk to daemon: chronyc nie dociera do usługi, bo chronyd nie działa. Powód poda systemctl status chrony. Komunikat wygląda tak samo przy każdym podpoleceniu chronyc.

chrony.service - chrony, an NTP client/server was skipped because of an unmet condition check (ConditionCapability=CAP_SYS_TIME).: system w ogóle nie ma prawa ustawiać zegara. Przy VPS opartych na kontenerach (LXC, OpenVZ) to przypadek standardowy, czas narzuca tam system gospodarza. Na serwerze root KVM system gościa może ustawiać swój zegar sam, więc tam ten komunikat jest prawdziwym znaleziskiem. Z perspektywy timesyncd ten sam przypadek wygląda tak: systemd-timesyncd.service - Network Time Synchronization was skipped because of an unmet condition check (ConditionVirtualization=!container).

Release file for ... is not valid yet przy apt update: zegar się spóźnia. Najpierw popraw czas, potem powtórz apt update. Odwrotnie, is expired wskazuje na spieszący się zegar, rzadziej na przestarzały serwer lustrzany.

Failed to query server: Connection timed out przy timedatectl timesync-status: timesyncd nie działa albo zastąpił go chrony. Jeśli aktywną usługą jest chrony, to polecenie na stałe pozostaje bez odpowiedzi, i nie jest to błąd. Właściwym narzędziem jest wtedy chronyc tracking.

Różnice między dystrybucjami w skrócie

Wszędzie natomiast obowiązuje to samo: strefa czasowa zależy wyłącznie od dowiązania /etc/localtime, a jedna usługa czasu wyklucza każdą inną.

Krótkie podsumowanie

Dla świeżo udostępnionego serwera root, który ma chodzić na czasie lokalnym i któremu wystarcza usługa domyślna:

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

Na końcu spodziewane są Time zone: Europe/Vienna, System clock synchronized: yes, NTP service: active i RTC in local TZ: no. Jeśli te cztery wiersze stoją tak samo również po restarcie, temat zegara tego serwera jest zamknięty.