Certyfikat, który odmawia walidacji, nieuporządkowane dzienniki lub zadanie uruchomione godzinę za wcześnie szybko mogą oskarżyć aplikację. Zacznij od sprawdzenia zegara maszyny. Na VM lub serwerze systemd, timedatectl pokazuje strefę czasową, usługę NTP i stan synchronizacji przed wprowadzeniem jakichkolwiek poprawek.
Celem jest oddzielenie trzech przypadków: błędny czas UTC, strefa czasowa pokazuje niewłaściwy czas lokalny lub synchronizacja sieciowa nie działa. Każdy przypadek wymaga innego działania.
Sprawdź czas, strefę i stan NTP
Najpierw odczytaj czas lokalny, UTC oraz stan zarządzany przez systemd. Dokonaj tej kontroli z sesji, która może pozostać otwarta, jeśli czas lub strefa czasowa muszą być zmienione.
date -Is
date -u -Is
timedatectl statusWynik wyświetla między innymi Czas lokalny, Czas uniwersalny, Czas RTC, Strefa czasowa, Zegar systemowy synchronizowany i Usługa NTP. Maszyna ustawiona na UTC może wyświetlać nieoczekiwany czas lokalny, zachowując jednocześnie właściwy moment. Porównaj więc date -u -Is z wiarygodnym źródłem przed oskarżeniem strefy czasowej.
W skrypcie unikaj parsowania wyświetlania status. Zapytaj o przydatne właściwości:
timedatectl show -p Timezone -p LocalRTC -p NTP -p NTPSynchronizedZmień strefę bez przesuwania zegara
Jeśli czas UTC jest spójny, ale czas lokalny nie, najpierw sprawdź, czy oczekiwana strefa czasowa istnieje:
timedatectl list-timezones | grep -Fx 'Europe/Paris'Następnie zastosuj strefę, a potem ponownie odczytaj jej wartość i czas lokalny:
sudo timedatectl set-timezone Europe/Paris
timedatectl show -p Timezone --value
date -IsTa komenda zmienia sposób prezentacji czasu UTC, nie resetuje zegara. Sprawdź timery i okna konserwacyjne po zmianie. Cron, jak 15 2 * * *, podąża za lokalnym czasem usługi, podczas gdy timer systemd może zadeklarować swoją własną strefę czasową.
systemctl list-timers --allPrzewodnik po timerach systemd i ich różnicach w porównaniu do cron pomaga w interpretacji tej listy. Zmiana strefy czasowej nie uzasadnia ponownego uruchamiania zdalnego serwera.
Aktywuj NTP z tylko jednym klientem synchronizacji
Przed użyciem timedatectl set-ntp true, zidentyfikuj już zainstalowanego klienta. W zależności od dystrybucji, zegar może być zarządzany przez systemd-timesyncd, Chrony lub ntpd.
systemctl list-unit-files | grep -E '^(systemd-timesyncd|chrony|chronyd|ntp).service'
systemctl is-active systemd-timesyncd
systemctl is-active chrony
systemctl is-active chronydNieaktywny serwis nie oznacza, że trzeba uruchamiać wszystkie inne. Utrzymuj tylko jednego klienta NTP. Na maszynie korzystającej z systemd-timesyncd, aktywuj synchronizację, a następnie sprawdź jej wynik:
sudo timedatectl set-ntp true
timedatectl show -p NTPSynchronized --value
timedatectl show-timesync --all
journalctl -u systemd-timesyncd -b --no-pagerWłaściwość NTPSynchronized=yes potwierdza, że systemd uznaje zegar za zsynchronizowany. show-timesync podaje także wybrany serwer i znane parametry timesyncd. Jeśli Chrony już zarządza zegarem, użyj jego narzędzi zamiast ponownie aktywować timesyncd. Artykuł na temat Chrony w systemie Linux omawia ten przypadek.
Unikaj ręcznej korekty na serwerze
Nie uruchamiaj timedatectl set-time, ponieważ dziennik wydaje się opóźniony. Ręczny skok może zakłócić certyfikaty, Kerberos, terminy sesji, blokady bazy danych i zaplanowane zadania.
Sprawdź także, jak Linux interpretuje zegar sprzętowy:
timedatectl status
sudo hwclock --showLinux zazwyczaj utrzymuje zegar sprzętowy w UTC. Jeśli RTC in local TZ wynosi yes, sprawdź politykę stacji roboczej przed przejściem na UTC, szczególnie przy podwójnym uruchomieniu Windows. Ustawienie to może przesunąć czas przy następnym uruchomieniu.
Po korekcie ponownie sprawdź timedatectl status, kolejne wykonania i dziesięć ostatnich minut dziennika odpowiedniej usługi. Jeśli moment, NTP i nowe zdarzenia się zgadzają, aplikacja często nie wymaga ponownego uruchomienia.
Dokumentacja timedatectl systemd opisuje zachowanie set-ntp oraz dostępne właściwości w zależności od zainstalowanej wersji.