Time wrong after power cut - how to fix?

Help and Support
1

I live in a rural area (overhead power cables) and suffer the occasional power cut in bad weather. Often when the power returns, OSMC displays the wrong time.
I believe this is because my Pi3 boots and checks NTP time before the router has had time to establish a fully functioning Broadband connection.
This raises a couple of questions;
(1) Is NTP queried periodically? If so, how often?
(2) If not (1) then what can I do to sync time once my broadband connection is fully functioning?
Thank you.

2

Simplest answer to (1) is wait and see :wink:
Simplest answer to (2) is re-boot the Pi.
You could also try ā€˜wait for networkā€™ in the MyOSMC network setup.

There are also some cheap real-time clock modules available for the Pi.

3

@grahamh, thanks for the reply.
We notice the wrong time quite a few hours after a cut so either it does not update periodically or the date/time is too far out. I think there is a limit to the difference that will be corrected but not sure.
A re-boot is what I am trying to avoid. I do that at the moment but lazy or in a hurry.
Unfortunately ā€˜wait for networkā€™ will not work as the router brings up the CAT5 switch a long time before a fully functioning Broadband connection is established.

4

Interesting question. According to this thread, it used to be a problem with nppd versions < 4.2.4p3 but it seems that OSMC has ntpd version 4.2.6p5, so, if the information is correct, should no longer be an issue.

The thread talks about the use of the dynamic option. You can find some information about that here under para. 18.3, though Iā€™m not clear if itā€™s supported in the current version of ntpd.

5 
root@osmc:/# systemctl status ntpd
ā— ntpd.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)
root@osmc:/#

Looks like I am (?we are) not using ntpd. My clock seems to be set by /usr/bin/http-time which waits 60 secs for a connection. Changing this to 600 secs (say) might allow enough time for the ISP to sort itself out.

BTW, @sam_nazarko if I run this script, it times out to 60s even though I do have an internet connection. I donā€™t have nfsroot in /proc/cmdline (why not ping google et al anyway?) or any output from connmanctl containing ā€˜onlineā€™.

root@osmc:/# connmanctl state
  State = ready
  OfflineMode = False
  SessionMode = False
root@osmc:/#
6 
osmc@osmc:~$ systemctl status ntp
ā— ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (running) since Sun 2017-05-28 23:01:08 BST; 14h ago
  Process: 525 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/ntp.service
           ā””ā”€533 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:110
7

I canā€™t believe thereā€™s not an embarassed emoji in the drop-down.

8

I have had the same problem with my Raspbian Pi2 which has the same version of ntpd, so apparently it is still an issue.

It happens infrequently enough for me that rebooting has worked well enough.

A better solution might be to set up a cron job to run X minutes after a reboot to restart ntp.

Add the following to your crontab file to run 2 mins after a restart

@reboot sleep 120 && /path/to/script_that_restarts_ntp.sh

and in the script, do this ā€¦

sudo service ntp restart

(just realized osmc doesnā€™t have cron running by default ā€¦ Iā€™m assuming that it can be installed in the normal way?)

9

I have NTP on my system.

We have three methods for setting time on OSMC:

  • We use fake-hwclock to restore the clock to the time before the last shutdown. This means that if there is no connectivity at all, weā€™re not in 1970.
  • We then use HTTP time to set the time from an Internet server. This gets us a reasonably accurate clock and avoids big jumps as Kodi starts, which can cause crashes. This only runs once on boot.
  • NTP then runs, which is now in charge of handling time. However some ISPs seem to block NTP traffic, which is another reason why we use the HTTP time service on boot.
10

I understand it was left out so as not to compromise performance. Itā€™s in the AppStore.

11

I already have CRON set up to run Flexget twice a day. Would this work?

sudo crontab -e, then add @reboot sleep 600 && service ntp restart.
A quick search suggests that sleep 600; is the correct syntax. Any idea which is correct for this OS?

That would give my router 5 minutes to establish a connection before querying the network time.

12

Or sleep 600 && systemctl restart ntp.

Looks good.

13

If you have to run that, somethingā€™s not correct on your network or system.
Itā€™s better to check ntp status after clock is off.

14

I was intrigued by this problem and finally got around to running a few tests.

My admittedly limited testing suggests that ntpd will eventually pick up the correct time once the internet returns, but it might take a while to do so. Hereā€™s the result of one test:

pi@raspberrypi:~ $ sudo route del gw 192.168.11.111
gw: Host name lookup failure
pi@raspberrypi:~ $ sudo route add default gw 192.168.11.1
pi@raspberrypi:~ $ while true; do date&&sleep 60; done
Mon 29 May 18:54:40 UTC 2017
Mon 29 May 18:55:40 UTC 2017
Mon 29 May 18:56:40 UTC 2017
Mon 29 May 18:57:40 UTC 2017
Mon 29 May 18:58:40 UTC 2017
Mon 29 May 18:59:40 UTC 2017
Mon 29 May 19:00:40 UTC 2017
Mon 29 May 19:01:40 UTC 2017
Mon 29 May 19:02:40 UTC 2017
Mon 29 May 19:03:40 UTC 2017
Mon 29 May 19:17:37 UTC 2017
Mon 29 May 19:18:37 UTC 2017

Iā€™d set the default gateway to a non-existent IP address, 192.168.11.111 and then set it to the correct address, 192.168.11.1. Then I waited (around 10 minutes) for the correct time to arrive.

Hereā€™s also a quote from the man page for ntpd:

should a server become unreachable for some time, the poll interval is increased in steps to 1024s in order to reduce network overhead

(I just love the precision of ā€œfor some timeā€.) So it seems that after a predetermined (but undisclosed) length of time, ntpd will increase its polling interval in steps of around 17 minutes before it will get around to trying again. That could eventually mount up if the internet connection was out ā€œfor some timeā€.

Conclusion: it seems to work as it should, but perhaps not how youā€™d expect (or wish) it to work.

Edit: Reading comprehension issues! ā€œā€¦the poll interval is increased in steps to 1024sā€ not of 1024s, which I guess is a bit better.

1 Like
15

I would be good if Gladfelder can confirm whether goosing ntp after 10 minutes (say reboot with the router turned off then turn it on) does the trick or there may be another issue as Sam says.

16

That would mean no DHCP. I also needed to simulate a lack of internet without trashing my connection, so settled on messing with the default gateway.