3

I've looked at the documentation but can't find anything like this. The situation is that I have a BeagleBone Black which does not have a real clock. By default, the computer boots up thinking it's 1999 (which is great for partying, but...). NTP fixes this, but only if the network is connected. Otherwise, it's 1999 again. And unfortunately, I neeTd the device in a location where it can't get internet access and also need to be logging times that make at least some sense.

It's occurred to me that it would be fine for my purposes if there was a way to get NTP to read a time from a file if the network was unavailable. I imagine that the time file would be written either as a cron job or something within NTP itself that maintained the state of this file.

Is there anything like this for NTP? Are there any alternative tools that would accomplish what I need? In particular that wouldn't be too much of a pain to set up on the BBB?

metasoarous
  • 698
  • 1
  • 7
  • 10

2 Answers2

4

You want the fake-hwclock package. It is specifically designed for situations like this. Description from the Debian package page:

fake-hwclock: Save/restore system clock on machines without working RTC hardware

Some machines don't have a working realtime clock (RTC) unit, or no driver for the hardware that does exist. fake-hwclock is a simple set of scripts to save the kernel's current clock periodically (including at shutdown) and restore it at boot so that the system clock keeps at least close to realtime. This will stop some of the problems that may be caused by a system believing it has travelled in time back to 1970, such as needing to perform filesystem checks at every boot.

On top of this, use of NTP is still recommended to deal with the fake clock "drifting" while the hardware is halted or rebooting.

Community
  • 1
dfc
  • 757
  • 6
  • 11
2

You could have a cronjob that ran every few minutes like this:

date +%s > /root/lasttime

Then have another cronjob (assuming you have a cron that understands advanced time settings, otherwise in a bootup script):

@reboot date +%s -s `cat /root/lasttime`

The first stores the time in seconds since epoch into /root/lasttime, then the reboot one reads the time from the file and sets the date.

So your time will be wrong by the amount of time the beagle was turned off. You may have a race condition where the first cron job might execute before the second, and so set the time to 1999, so it is best to make it infrequent or put a check in to make sure the time makes sense before storing it.

Paul
  • 61,193