Time-setting upon reboot without harware clock

Frustrated by openwrt booting up with wildly obsolete time, causing certain time-sensitive apps to break upon restart, I finally tracked down /etc/init.d/sysfixtime, which reportedly sets the openwrt syste clock using the timestamp of the newest file in /etc to a "reasonably" approximate time, on hardware that has no RTC or battery for time-keeping.

A gander in / shows it is probably the "best" approach. However, it is still not good enough for my hardware that has no hardware clock or battery. Even though mine is plugged into a UPS, sys time after reboot is still often wildly off, I guess because my /etc doesn't get changed THAT often.

I have been manually executing "ntpd -qnN -p [ip-addr-of-some-ntp-server]" to force-adjust systime after reboot, in order for the affected apps to start up correctly. I'm wondering what the best approach is to automate this:

  • Append the ntpd commands in /etc/init.d/sysfixtime? I realize this assumes internet or LAN network access, while checking /etc doesn't. Is ntpd likely to be removed from the default openwrt (base?) install in the future?
  • Use a shutdown script to write an empty file in /etc? Or, is there a better approach?

Changed /etc/init.d/sysfixtime would get overwriten by new openwrt (snapshots) installs, so it doesn't cover that scenario. Can shutdown script be preserved in /etc/sysupgrade.conf and survive new openwrt snapshot install?

Are there any other approaches?

see Problematic system - #36 by uniquename

It works for me with time sensitive WireGuard,

Tue Jan  1 00:00:05 2030 daemon.info dnsmasq[3002]: read /tmp/hosts/dhcp.cfg01411c - 9 addresses
Tue Jan  1 00:00:05 2030 daemon.info dnsmasq-dhcp[3002]: read /etc/ethers - 0 addresses
Sat Jan 23 05:59:42 2021 cron.err crond[1621]: time disparity of -4701245 minutes detected
1 Like

There is only one real solution, getting a device with battery backed rtc - everything else is just trying to approximating the time and diving (deeper-) into race conditions or expecting too much from the conditionals of the network coming up.

5 Likes

In normal situations, the router does not reboot and the time remains valid.

If you have known /planned reboots, the best approach is to help sysfixtime to have a reasonably good time from a file in /etc

Or if your router crashes often, you might write a file in /etc every hour, or so. That would marginally shorten the lifetime of flash, but likely no issue.

When I want to "save time", I use /etc/urandom.seed that is in overlay in any case.

1 Like