For å løse en spesifikk tidssonerelatert feil på et programvareprosjekt som jeg jobber med, prøver jeg å replikere en endring på systemet » s klokke med timedatectl for å sjekke programvareoppførselen min.
Jeg prøver å oppnå det ved å kjøre
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 Når jeg gjør det og kjører timedatectl rett etter, får jeg forventet følgende tid:
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 Men 10 sekunder etter dette, når minuttet endres (til xx:59), vil den lokale og universelle tidstypen «omstarte» til gjeldende tid
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 Hva mangler jeg her?
Oppsettet mitt er en Vagrant Ubuntu 18 VM (Linux vagrant 4.15.0-51 / vm boks «bento / ubuntu-18.04»).
Kommentarer
- Det kan godt hende du oppdager at VM-tiden din er synkronisert med verten din ' sin tid. Ikke kjent med Vagrant, så ' t kan peke deg på en løsning.
Svar
Dette forklarer ikke oppførselen du ser, men det burde svare på spørsmålet i tittelen.
I stedet for å endre systemets tid, kan du bruke et verktøy som faketime og TZ miljøvariabelen:
$ 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 Dette lar deg kjøre programmet med sin egen tidssone, dato og tid, uten å påvirke resten av systemet.
Merk at det bruker et $LD_PRELOAD hack for å injisere kode i applikasjoner, det vil ikke fungere for statisk koblede kjørbare filer eller setuid / setgid kjørbare filer.