On Tue, 18 Feb 2025 at 12:47, Roberto A. Foglietta <[email protected]> wrote: > > On Mon, 17 Feb 2025 at 18:24, ruggero rossi <[email protected]> wrote: > > > > On Tue, 18 Feb 2025 00:22:16 +1000 (AEST) > > David Leonard <[email protected]> wrote: > > > > Hello David, > > > > This is the first time I've thought about NTP eras, so I'm not sure my > > reasoning is correct, but here are my considerations: > > in lpf_to_d, d was calculated by adding 1<<32 to dates < 1970, so d is > > always the number of seconds since 1900-01-01T00:00:00.0 - no era here. > > > > A quick workaround to all the issues related to this kind of > "problems" is to set the system date/time somewhere on 2000-01-01 > everytime the system boots with a date/time nearby 1970-01-01. Which > was what I was used to doing for the embedded systems I was working on > and was lacking a battery for their RTC. In particular, scheduling a > cron task for which each minute it will save the current date/time on > the writable support (reboot persistent memory) which was functioning > also as a watchdog about the writability of that support, just in > case. At boot time, I set the date/time from the last time and then > update/synchronize it with whatever real-time source I was able to > access. >
Good morning, You can also extend my suggestion and propose a patch to modify the busybox creating a watchdog that instead of simply triggering the kernel watchdog every X seconds, it write a file indicated by an option, in which it puts the date/time in a text form that can be immediately be used by busybox date to set the system clock and in case of failure avoid to trigger the kernel watchdog which will leads to a reboot after 1 or more failures. busybox keepalive -k /dev/watchdog -s 60 -w /etc/datetime.last Even better, in writing the file using a direct I/O access and fsync the file. Then read it back and check the value to be sure that the write has been moved from the cache to the device in a proper manner. Which is important for some extreme condition functioning system or when the storage failure did not lead to a read-only condition of the device. On my embedded systems, the reboot also provide a fsck before trying to mount the root filesystem while the basics tools where stored into initramfs to take care of it. Best regards, R- _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
