Duplicated Entries about vnstat

[vergoh]

That's some strange behaviour. Few questions:

1. Was 1.14 already in use when those problems started?
2. Your hostname suggests that's a laptop. What sort of connectivity/usage does wlan0 have, always connected or more like random usage with disconnects?
3. Is hibernate and/or suspend getting used?
4. Is ntpd configured and running?

Assuming the daemon was in use and you don't have a quick log discard, it would be interesting to see what the vnstatd output was around 31.7.2015. That could contain some clues why the duplicates happen.

[AlexMl]

1. I used 1.11-2 from the official ubuntu repositories and upgraded to the latest version in mid July. So the duplication happened with both versions.
2. wlan0 is my main network device and it usually does not have disconnects.
3. Suspend mode is used frequently hibernation not at all.
4. ntpd is not installed/used

Unfortunately I only have syslogs from August which is weird but not related to this.
I switched to a different time zone and back some time ago. Do you think this is related.

[AlexMl]

I just noticed that I changed the system time on the 31 of July.

[AlexMl]

Ok Im pretty sure the duplicated entries are caused by changing the system time. Is there a way to edit the database of vnstat?

[vergoh]

Yes, that indeed appears to be the likely case. Either bad timing with the system time change or changing to a timezone far enough from the previous. I'll have to see if I could come up with some sort of sanity checker that would merge that kind of duplicated days/months when the database is loaded.

It's possible to edit the database like this:

1. use --exportdb and pipe the output to a file
2. modify the file, the format is explained in the vnstat(1) man page
3. stop the daemon before import
4. make a backup of the original database file
5. use --importdb to import the modified text file
6. check with vnstat that the modifications are as intended
7. restart the daemon

If you don't mind, could you show the output of --exportdb before editing it. The timestamps are likely to give some idea how the duplication happens and how it could be either prevented or merged back.

[AlexMl]

Here is the exported database: https://gist.github.com/AlexMl/758a22e8f75673196683

The time change was about 7 or 8 hours if it matters.

[AlexMl]

I had time to fix the database today. Thanks for your help. Everything is fine again.
One last Question:

m;0;1438380001;81047;4361;897;955;1

What are the last three numbers for? I read the manpage but did not understand it.

[vergoh]

On that line, 897 is the rx KiB value for the current month and 955 is the corresponding tx value. This structure is due to vnStat historical reasons. For getting the rx value in KiB, you'd count 81047 * 1024 + 897 and in a similar way, tx for that line is 4361 * 1024 + 955.

The last number is either 0 or 1 depending on whether that line has already been filled by vnStat and it's being shown in outputs. Usually it will show everywhere as 1 if the database has been in use for longer than 11 months.

[Misiek304]

It's happening for me too on my OpenWRT router. Sometimes when there's an power outage vnstat get's all messed up and it doubles the entries like in the screenshots above.

[vergoh]

Hopefully the switch to the sqlite database will make this problem go away as I don't have a good understanding how to replicate it in order to better understand what's happening and why. At least based on sqlite's documentation, it should be better at handling partially completed writes that are likely to happen during a power outage. I suspect that's something the filesystem in OpenWRT doesn't do be itself.

[vergoh]

sqlite database implementation has been merged from the branch to master and will be included in vnStat 2.0 release.