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 #160 automatically too, immediately after the drifts sync back to normal if its possible. So do you have any insight about this ?

Thanks...