The sysfixtime is in base-files, and not available as a separate component to disable. The script uses hwclock, which I can disable in Linux system utilities, but this must not be the right way to do.
T be honest I am not sure why this functionality is useful. Time from the file system will anyway be incorrect, while considered to be "close". In case of long downtime it will be totally incorrect, and what I actually experience with it - it is hard to match time and perform research of logs. Timestamps go back and forth when device is not shut down properly or fails. Given that there's no built-in functionality for logging the NTP time corrections (I had to put this into the build manually).
Thus, for proper system implementation, RTC backed up by the battery is mandatory. If RTC is not in there, I have made a decision to reset CPU built-in RTC to 1970-01-01 00:00:00 in the U-boot to ensure logging will start with default time, and not some time which seems to look like valid time - until it is corrected by the NTP with appropriate message logged.
With a completely incorrect time, such as 1970, DNSSEC, DoH, DoT, etc., will not work.
The NTP client will also be unable to resolve domain names or synchronize the time.
However, with a slightly incorrect time of ~30 minutes, this usually works without any issues.
There are several approaches for such systems:
Retrieve the time from the file system.
Specify an IP address as the NTP server (though this is usually not ideal, as most pools have dynamic IP addresses).
Ok, let's say there must be a balance and specific purpose. The issue I am raising I do not see how to disable it. Let's say if my platform has RTC I will get time out of there, but if no RTC or RTC has failed then I will consider using sysfixtime functionality. How to implement it properly? How to run sysfixtime conditionally, or start it manually if needed? No options to change in /etc/config/...
looking at the script itself loads from /dev/rtc0 at boot. script only saves itself when this service is stoping, but not sure if this service ever actually stops in normal lifecycle of router.
Correct, there's no flag if it is allowed to be active or not. It always starts and runs. Ok, let it run as it is updating timestamp file on shutdown (thus keeping its track), but there must be a functionality to prevent this service updating the system time. Right now, the only way to do it legally is to remove hwclock from the system
to have $HWCLOCK not existing. But in this case the functionality is totally broken and can't be enabled on the fly.
Edit: I must make a clarification at this point. the system I use DOES HAVE real time clock device physically, but it is not wired / powered properly and powers on with invalid data in it.
Hm, I am not sure, but it might be the solution. Running /etc/init.d/sysfixtime disable seems to disable the service and boot() and start() are not being operated after the reboot.
Where this disable state is saved? In the generic help page it just says "disable service autostart", status reporting using /etc/init.d/ not available, service in the common listing (when run without arguments) shows that service is disabled (and this is the only way to see its status).
Simply genius, thanks. Then it seems my problem boils down to disabling functionality of find_max_time(). If I disable this service, I'd be able to use hwclock to update the /dev/rtc0 manually in my script when required - just to keep it in sync.
That has actually always been the weak point of all possible solutions.
If the system lies that it has a hardware clock, and it is not a real one with battery backup, there are difficulties. There have been a few routers with this kind of the "fake RTC". See discussion in https://github.com/openwrt/openwrt/pull/3418 , six years ago. Thta PR aimed to fix the problem to the extent possible.
Most routers are without any RTC, and then the approach of taking the last file date/time stamp from /etc as the approximation, works well. It is the best known data. Note that by default OpenWrt writes almost nothing to flash, just the initialisation of random data seed to /etc/urandom.seed at the end of the boot process. (Originally a virgin router starts from the compilation date/time.)
With a real RTC hwclock, it also works well. And there is the saving at shutdown, helping to correct a possible drift.
One way for you could be to touch a file in /etc every 12 hours (especially if you have no flash, but a HDD. That would enable 12-hour granularity for boot time even with the default script.
I made a script earlier to cross check the last timestamp to the TSF increment rate from the beacons of all nearby AP to also keep track of time when your router is down or reboots. Never got to making it production ready yet unfortunately.