search

vergoh / vnstat

vnStat - a network traffic monitor for Linux and BSD
GNU General Public License v2.0
1.36k stars 120 forks source link

Wrong date if you want to track the daily use #240

Closed hofersimon closed 1 year ago

hofersimon commented 1 year ago

Hey, I recently installed vnStat with the Fedora repos (sudo dnf install vnstat), I wanted to check how much I've used today and I noticed that it shows 2022.11.28 and not today's 2022.11.30.

As you can see in the picture, vnstat uses the 28th, but when i run "$ cal" then my system time is the 30th (which is the correct time). Screenshot-20221130160338-891x510

Bye, Simon

vergoh commented 1 year ago

Which release of Fedora is that and which version of vnStat did it install? Have you checked the vnstat daemon (vnstatd) is running and configured be automatically started?

hofersimon commented 1 year ago

Hey, I'm currently running Fedora 37. Version: 2.9

Now it's showing up the current day, but above it is still stuck at the 2022-11-28. image

vergoh commented 1 year ago

What does systemctl status vnstat output?

hofersimon commented 1 year ago

It's showing… image

But I don't know how, but overnight it fixed itself?? Now it's working as usual, thanks anyway for your time.

vergoh commented 1 year ago

The output you get when executing the vstnat command when there are multiple interfaces in the database contains the previous month and the current month + the previous day and the current day when those are available. The previous month and day will show the previous monitored day so if there's a gap in either the system or vnstat daemon uptime then "previous" may not be the same as "previous" from calendar perspective.

Looking at the systemctl status vnstat output, it points out that the service isn't enabled by default ("preset: disabled") after being installed (unless something the automatically configures it(?)) so it can be possible that systemctl start vnstat got executed earlier but systemctl enable vnstat wasn't. That would have resulted in the daemon starting for the ongoing session but not after the systeam was later rebooted. Now that the status shows "enabled" everything should be fine.