vnStat stuck on future date after Chrony service finished date/time sync

[imamalfatah]

Hi, i face same problem like issue #160 and want to ask is there any way to fix vnstat stuck issue automatically ?
Sorry if this question also related to another program..

Background problem:
My device is RaspberryPi, there i have Chrony service to tackle date/time drift issue automatically. So in my testing i did set date/time manually +1 day to future and Chrony did the job to sync it back.
But after Chrony finished the sync time back to normal (i have confirm it back to normal), and i leave my device for couple of hour then i just realized that Vnstat continue the network monitoring still in +1 day in future, even though the system date/time has been sync to normal..

This some logs that i have:
Oct 23 03:15:45 beam vnstatd[805785]: Info: Latest database update is in the future (db: 2024-10-24 03:11:40 > now: 2024-10-23 03:15:45). Giving the system clock up to 5 minutes to sync before continuing.
Oct 23 03:20:45 beam vnstatd[805785]: Info: Latest database update is still in the future (db: 2024-10-24 03:11:40 > now: 2024-10-23 03:20:45), continuing. Some errors may follow.

Question:
So any idea how to tackle this issue automatically ?
Thanks in advance..

[vergoh]

vnStat doesn't have any built-in time synchronization functionality so only the current date/time being too much in the past (=more than timezone change could result in) compared to the latest database write can be detected. As you can see from the log, the implementation will wait for a configured time to let possible other system services do the synchronization before continuing.

Since you did change the date only by one day to the future, I'd expect the issue to have fixed itself by itself due to enough time having passed. Otherwise, the database edits explained in #160 would have been the alternative.

[imamalfatah]

Understood, thanks for the response..
Another quick question, since in #160 it mentioned works for vnStat version 2.0, what about vnStat version under 2.0 ?
Also i think i ever did solve the stuck issue with only restarting the service, but sometimes it can not solve it, can i say that restarting the service not really have guarantee to solving the stuck issue ?

[vergoh]

vnStat 1.x versions use a less advanced database solution resulting in those instructions not being applicable. If the vnStat 1.x database needs to be modified then it requires exporting the database content to a text file, modifying that text file by removing the problematic entries and then importing it back while hoping nothing got corrupted.

Does you RaspberryPi have a clock which drifts towards the future or what's the situation that causes this "stuck issue" if you haven't intentionally manipulated the system time?

I recall the RaspberryPis are mainly missing an RTC chip which means that the date/time resets if the system is rebooted or powered off. Most distributions try to minimize the effect by writing down the current date/time during shutdown and then restoring that date/time during boot and then starting some NTP client to sync for the actual time. With this setup, I don't see how the date/time would drift towards the future and that setup is also something vnStat is able to handle.

[imamalfatah]

The RaspberryPi here as IoT device, we still not investigate in more detail about the root cause that make drifts because its not really frequent, but happen one or two times. We have RTC chip in it, so i think the problem not related to that..

Because of that we relying with NTP server to be able sync the system time if the drift happen some times in the future, but while testing it with manual intervention in this case we just realized that vnStat still stuck on future date even after Chrony service that handle the NTP finished the time sync and make the system time normal again..

So maybe the last 2 question from me is,

1. While doing testing with setting the time to future +1 day to future, I keep see on vnStat log that it said trying to handle the future date issue within five minutes (same as log that i have sent in previous message), but so far it never success until i wait to tomorrow that indeed the system time will be same like what currently on vnstat DB has. So how long exactly vnStat can handle based on that logs information ?

2. Just in case you know since we set the RaspberryPi as IoT device that we not really would control it frequently, so we relying to Chrony service to communicate with NTP server to sync the time if the drifts happen, automatically. Then we planning to execute the query that explained in vnStat stuck on future time #160 automatically too, immediately after the drifts sync back to normal if its possible. So do you have any insight about this ?

Thanks...

[vergoh]

Sorry for the reply delay, I appear to have missed your reply and the extra questions.

1. The default configuration (controlled with TimeSyncWait) in vnStat is to wait for up to 5 minutes if the clock's current time appears to be in the past compared to the time vnStat's database was last updated. vnStat will check every 5 seconds if the clock still shows a date that older that the previous database update date and if the clock adjusts itself during this time (most likely due to a NTP sync) then vnStat will continue normal operations. If the 5 minute wait expires then it's assumed that the previous database update date may have been incorrect an normal operations resume again. However, any data in the future in the database doesn't get cleaned away. As you did adjust the clock manually to be in the future, vnStat will not "succeed" during those 5 minutes in getting the "correct" time unless you manually adjust it back to the future during that time.

2. How have you configured Chrony?
   Looking from it's documentation, it has a configuration option called makestep which isn't enabled by default: https://chrony-project.org/doc/4.6.1/chrony.conf.html#makestep
   When it's not enabled, it will cause Chrony to correct the time offset by having either longer or shorter seconds. This can obviously take a lots of time depending on how long the offset it. With makestep, it's possible to make Chrony jump time directly to what NTP servers tell as being the current time if the offset is too large right after system startup. I recall at least the Raspbian distribution had this kind of setup for RaspberryPi's back when ntpd and ntpdate were used.

If you need to do these sort of "jumps to the future" time changes for a short duration for testing purposes and you care about vnStat's data then I'd suggest stopping the vnStat daemon before manipulating system time and then restarting it once time has been synced back to normal. That way the future timestamp would get written to the database and vnStat wouldn't wonder if the clock is really now in the past or not.