Aby naprawić błąd związany z określoną strefą czasową w projekcie oprogramowania, nad którym pracuję, próbuję odtworzyć zmianę w systemie s zegar używając timedatectl do sprawdzenia mojego działania oprogramowania.
Próbuję to osiągnąć, uruchamiając
timedatectl set-timezone America/New_York timedatectl set-local-rtc 1 timedatectl set-ntp false timedatectl set-time "2017-03-12 01:58:50" && hwclock -w Kiedy to robię i zaraz potem uruchamiam timedatectl, otrzymuję oczekiwany następujący czas:
Local time: Sun 2017-03-12 01:58:51 EST Universal time: Sun 2017-03-12 06:58:51 UTC RTC time: Sun 2017-03-12 01:58:51 Time zone: America/New_York (EST, -0500) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: yes Jednak 10 sekund po tym, gdy minuta się zmieni (na xx:59), lokalny i uniwersalny rodzaj „restartu” na aktualny czas
Local time: Wed 2019-08-07 21:01:41 EDT Universal time: Thu 2019-08-08 01:01:41 UTC RTC time: Sun 2017-03-12 01:58:57 Time zone: America/New_York (EDT, -0400) System clock synchronized: no systemd-timesyncd.service active: no RTC in local TZ: yes Czego tu brakuje?
Moja konfiguracja to Vagrant Ubuntu 18 VM (Linux vagrant 4.15.0-51 / vm box „bento / ubuntu-18.04”).
Komentarze
- Może się okazać, że czas maszyny wirtualnej jest zsynchronizowany z czasem ' hosta. Nie znasz Vagranta, więc nie mogę ' wskazać Ci rozwiązania.
Odpowiedź
To nie wyjaśnia zachowania, które widzisz, ale powinno odpowiedzieć na pytanie w tytule.
Zamiast zmieniać czas systemu, możesz użyć narzędzia takiego jak faketime i zmienna środowiskowa TZ:
$ date; faketime -f -15d date; TZ=America/New_York faketime -f -15d date Thu 8 Aug 10:21:13 CEST 2019 Wed 24 Jul 10:21:13 CEST 2019 Wed 24 Jul 04:21:13 EDT 2019 Umożliwi to uruchomienie programu z własną strefą czasową, datą i godziną bez wpływu na resztę systemu.
Zauważ, że używa $LD_PRELOAD hackowania do wstrzyknięcia kodu w aplikacjach, nie będzie działać w przypadku plików wykonywalnych połączonych statycznie ani plików wykonywalnych setuid / setgid.