I have a Raspberry Pi. It has no RTC.

When it loses power, it has no idea how long it's been off until it checks the current time with NTP.

I installed ntpd on it, and am running it as a systemd service. That works fine.

I have software running on the Pi that does non-essential, time-based stuff. That means that if the current system time is accurate, it can do the task, but if the current system time may or may not be accurate, it can (and should) skip the task.

The way to know if the system clock is accurate, conceptually, seems simple - if the system has successfully used ntpd to update its time since it booted, the clock is accurate. Otherwise, assume the clock isn't accurate.

Is it possible to somehow get ntpd to tell me if it has successfully connected to the internet, retrieved the current time, and updated the system clock since last boot? I would rather not have my software try to parse ntpd's logs, if I can avoid it.

  • FreeBSD (and perhaps other BSDs) has an rc.conf feature ntpdate_enable. If set to yes then at boot time, FreeBSD will use ntpdate to do a one-time clock set. Then, if one has also enabled the ntpd service, ntpd is launched, and keeps the clock syncronized from that moment on. By enabling both of these features, one can ensure that the clock is set accurately once at start-up, and that ntpd is launched to keep the clock in sync thereafter. Your OS may have a similar feature. – Jim L. Mar 18 at 20:01
  • if you run auditd, all adjustments are logged in audit.log. Using ausearch to look for those adjustments might be a way to go... – Jakub Lucký Mar 18 at 20:36
  • @JimL. That assumes you have internet during boot, which isn't always the case. I have software that needs to start at boot. It can't sit around waiting for internet to be available at boot, for NTP to run, and clocks to be accurate before it starts up. It just needs to know if the system time is accurate or not at a particular point in time – John Mar 18 at 20:44
  • Adding a cron job to run ntpdate @reboot may be another alternative. – Jim L. Mar 18 at 20:45
  • @JakubLucký auditd doesn't appear to come pre-installed on the Pi's OS. It seems a little overkill to install an entire auditing system just for this one small byproduct of it. At that point, it might be easier just to read ntp logs – John Mar 18 at 20:45

To see whether NTPD has worked - can't you enable logging for ntpd?

Configuring ntpd log file AND RaspPI specific changes may be needed

And then run ntpstat (or whatever the equivalent on Debian is) or look at the logs to see what it's doing?

# ntpstat
synchronised to unspecified at stratum 6
   time correct to within 465816ms
   polling server every 1024 s
  • Thanks. I haven't looked into parsing ntpd's logs yet, and it's definitely an option (I even mention it in my question at the end), but it's a last resort. Logs are meant to be read by people. Log output (wording) can be changed by the program (ntpd developers) at any point, without regard for what parsing scripts it might break, because it's not meant to be read by parsing tools. Parsing logs is inherently unreliable. ntpstat on the other hand appears to ask the ntp daemon directly, and seems like a good option. – John Mar 19 at 14:53
  • 1
    Lots of other good ideas here cyberciti.biz/faq/linux-unix-bsd-is-ntp-client-working - I've used ntpq before and it worked reasonably well.. Apparently the return code of ntpstat varies 0 is good, 1 is not synchronized, 2 is no idea.. – Mr R Mar 19 at 14:58
  • 1
    Playing around with ntpstat for a few minutes, and reading through its documentation, it seems perfect. It has an exit code that returns 0 if clock is synchronized, and 1 if clock is not synchronized, which is literally meant to be used by scripts. Way more reliable than parsing logs. Perfect. – John Mar 19 at 14:58

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.