2

I'm using a Raspberry Pi 2 (Jessie) to log some data. It only runs for a few hours at a time. When I boot it, the clock is wrong. This has been discussed at length in a number of threads.

I'd like to wait until the clock is correct. Normally, before a synch, it displays the time it was shutdown, so I suspect it has fake-hwclock. The problem with this is that I can't simply wait until the clock is no longer 1st Jan 1970.

So I went with another suggested approach: to grep /var/log/syslog for "Time has been changed". The problem with this approach is that the syslog contains a record of EVERY instance where the time was changed.

Is there a log or something which contains only the system log for the present session (i.e. since last boot)? Does it contain a log that the time has been changed?

Are there any other suggestions as to how I might wait until the clock has been set after a boot? I won't be adding an RTC: the timestamp is just a nice-to-have. in fact, I can achieve everything else I need just with Python's time.monotonic().

  • 1
    Instead of parsing the output of a file why not add a RTC (real time clock) to your Pi. Having said that you could try this ntpq -p | grep * | cut -c1-1 This will return an * if the clock is synced. – Steve Robillard Sep 12 '16 at 22:08
  • Not sufficiently worried about the timestamp to add an RTC. If I could hack it in software it'd be a bonus. I never thought of simply forcing the synch and waiting for completion... – KDM Sep 12 '16 at 23:00
  • 1
    You could just disable the fake-hwclock – Milliways Sep 13 '16 at 6:55
  • Hmmm... yes. Then I could detect if it was still 1970. Didn't know disabling this was an option. – KDM Sep 13 '16 at 19:39
3

ntpd is what is syncing your time, normally it tries to slowly adjust the time to stop time suddenly jumping forward or backwards. The exception to this is when the clock is out by a large amount. This is likely the case when you boot, but still takes some time to adjust.

You can force the sync your self with ntpdate 0.europe.pool.ntp.org as root (select your closest time server from here). However you cannot run ntpdate while ntpd is running, so you must stop it first. Given you are only booting the pi for a few hours the clock drift is negligible during this time (almost immeasurable) you do not need to run ntpd at all. Instead you can get your application to sync the time manually before doing what it needs to do with ntpdate, once it returns the time is in sync.

Note that sometimes it requires a couple of runs to fully sync up, luckily ntpdate reports the current offset in its output, you can parse this until it is an acceptable amount.

  • The iburst option to the server entries will help to speed up ntpd sync-ing on start-up, the man details are: When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16s to allow a modem call to complete. Once the server is reachable, the spacing between packets is about 2s. This is designed to speed the initial synchronization acquisition with the server command and s addresses and when ntpd is started with the -q option. – SlySven Sep 14 '16 at 1:14
  • Discussion in and below this answer suggests ntpdate is depreciated and something different should be done instead. Would that apply here to RPi here as well? – uhoh Mar 11 '18 at 19:44
  • You might be able to use systemd-timesyncd and timedatectl to set it if your distro supports it. – Michael Daffin Mar 11 '18 at 23:42
  • You can also use ntpd -qg as well - it mostly depends on which distro you are using though, if systemd-timesyncd is running I would use that, if ntpd is running use ntpd -qg or ntpdate. – Michael Daffin Mar 11 '18 at 23:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.