After NTP synchronization if I try to enquire the host OS over Dbus immediately, I observed it returning false. I am using that timestamp with NTP synchronization as my status, but it’s returning that the correct synchronized time is false.
Should I consider any delay before enquiring NTP synchronization over Dbus after NTP is synchronized to receive the correct status?
Raspberry pi 1. Version:2.12.6.
I am checking as give in the link.
Hi,
I’m not entirely sure I understand the part where you mention that you check NTP is synchronised and then check via DBUS separately.
The documentation to check NTP time is via DBUS. There is a dict entry that has the string NTPSynchronized. Once that is returned true, time is synchronized. And the same dbus return has an entry for timeUsec which is since epoch. Does the next DBUS query immediately afterwards return false in NTPSynchronized? I checked on a Beaglebone + v2.16.7 I had running and ran dbus-send in a loop and that only returned NTPSynchronized as true.
The only thing I can guess is that you ran timedatectl and that returned NTP synchronised: yes And then immediately afterwards, ran the DBUS command which didn’t yet respond with NTPSynchronized?
Jul 03 15:52:54.349 DEBUG: Time: 2018-07-03T15:52:54.296279, Status: 0
Jul 03 15:52:54.409 DEBUG: Time: 2018-07-03T15:52:54.360286, Status: 0
Jul 03 15:52:54.470 DEBUG: Time: 2018-07-03T15:52:54.423509, Status: 0
Jul 03 15:52:54.564 DEBUG: Time: 2018-07-03T15:52:54.490940, Status: 0
Jul 03 16:04:17.336 DEBUG: Time: 2018-07-03T15:52:54.567291, Status: 1
Jul 03 16:04:17.399 DEBUG: Time: 2018-07-03T16:04:17.339340, Status: 1
Jul 03 16:04:17.486 DEBUG: Time: 2018-07-03T16:04:17.402687, Status: 1
Jul 03 16:04:17.579 DEBUG: Time: 2018-07-03T16:04:17.489604, Status: 1
Jul 03 16:04:17.690 DEBUG: Time: 2018-07-03T16:04:17.582426, Status: 1
Jul 03 16:04:17.834 DEBUG: Time: 2018-07-03T16:04:17.720717, Status: 1
Jul 03 16:04:18.059 DEBUG: Time: 2018-07-03T16:04:17.837725, Status: 0
Jul 03 16:04:18.200 DEBUG: Time: 2018-07-03T16:04:18.083674, Status: 0
Jul 03 16:04:18.330 DEBUG: Time: 2018-07-03T16:04:18.219710, Status: 0
Jul 03 16:04:18.454 DEBUG: Time: 2018-07-03T16:04:18.362811, Status: 0
Status here is “NTP synchronised:” response of DBUS query. It returned False like above for about 32 secs after NTP synchronized and then it’s returning True.
for example Jul 03 16:04:18.330 DEBUG: Time: 2018-07-03T16:04:18.219710, Status: 0 here time is NTP synchronized but it returned False. I can see the correct status again after 32 secs. Do I need to consider some delay in checking for NTP synchronization over Dbus?
so, it’s returning True after NTP synchronized and then the subsequent queries returning False for 32 secs and True from then onwards.
Hi,
Looks like time is loosing sync for some reason. It really shouldn’t…
I replicated your setup
root@e476a7d:~# cat /etc/os-release
ID="resin-os"
NAME="Resin OS"
VERSION="2.12.6+rev1"
VERSION_ID="2.12.6"
PRETTY_NAME="Resin OS 2.12.6+rev1"
RESIN_BOARD_REV="c1ac9a0"
META_RESIN_REV="b744564"
SLUG="raspberry-pi"
MACHINE="raspberrypi"
VARIANT="Development"
VARIANT_ID="dev"
root@e476a7d:~#
And then from inside a container
root@e476a7d:/usr/src/app# while true; do DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --print-reply --reply-timeout=2000 --type=method_call --dest=org.freedesktop.timedate1 /org/freedesktop/timedate1 org.freedesktop.DBus.Properties.GetAll string:"org.freedesktop.timedate1" | grep -i sync -C2 | grep -i false; done
Didn’t see NTP respond false at any point.
Not really sure what else we can do if we cannot replicate it.
Time/NTP should not loose sync unless something is messing with clocks/network times etc.
Hi,
Whenever I loose internet for an extended period of time and a power cycle(Where fake hw clock fails) when there is no internet, I loose NTP. After power cycle, when I get internet back if I keep checking for NTP synchronization, I observed that there is a NTP sync happened, the status was true for less than 1 sec and then the status returned false(I can read correct NTP time in this period) for 32 secs and then it was true thereafter.
I see.
Looks like NTP is taking a bit of time to stabilise. And there is a one-off NTP Sync status reported but then NTP thinks it has synchronised before settling down.
I’d recommend re-checking NTP Synchronisation once every second for 10 times. If it is true for 10 times, consider the time to be correct. This will disregard the one-off NTP Sync status you see.
In resinOS v2.13 we have moved to a better NTP daemon called chrony. The previous one was systemd-timesyncd. It might be better but I cannot guarantee that you won’t see similar behaviour. I’d still recommend that you check NTPSync 10 times via dbus over 10 seconds before considering time to be accurate.
I am not sure the method is right for you or not.
I will try to copy the /etc/timezone to target. If you build your image, you need to copy it to your Dockerfile. Before copy this file, you are able to check the timezone as your wanted timezone.
Don’t forget export it in your Dockerfile
Ref. How to modify the timezone~
https://www.thegeekstuff.com/2010/09/change-timezone-in-linux/
Secondly, you write a crontab via command line to schedule “@reboot /etc/init.d/ntp; sleep 10; /usr/sbin/ntpd -q -g; sleep 10; /etc/init.d/ntp start”
Ref. How to append your cron job via command line manually~
Thanks