1

I've been testing Ubuntu 16.04 to 18.04 upgrade. I upgraded last week and I rebooted 18.04 tonight. Notice how conky shows gaps for vnstat:

vnstat 18.04 reboot.gif

  • "Yesterday" is blank but there should be 8.76 GB.
  • "Week" shows 7 GB but should be 32.33 GB + 2.52 GB for 18.04 boot tonight.
  • "Month" shows 45.63 GB but it really is about 70 GB

The reason is 16.04 and 18.04 have separate databases that aren't synced when I clone 16.04 to test partition and upgrade to 18.04: Bash script to clone Ubuntu to new partition for testing 18.04 LTS upgrade

How can I have Ubuntu 16.04 on one partition and Ubuntu 18.04 on another partition both updating the same vnstat database? I would like to store the database on a third partition (ntfs File System) already setup for sharing Windows Subsystem for Linux (WSL) data and Ubuntu data.

Bonus: assuming I can collect Daily RX/TX/Total stats in Windows, how can I populate them into the vnstat database?


EDIT 1: Using accepted answer 16.04 and 18.04 are both updating vnstat 16.04 version data files in ntfs formatted partition /mnt/e/var/lib/vnstat/. I had to roll-back Ubuntu 18.04 vnstat version 1.18 and pin it to the Ubuntu 16.04 version 1.13 aka 1.14-1.

The next step will be to get Windows 10 WSL to "see" the data and display it somehow. After that get WSL to run vnstatd daemon on boot and collect/update network bandwidth statistics.

1 Answers1

3

vnStat versions 1.3 - 1.18 use the same database structure so sharing a database with those versions is possible as long as

  1. both installs share the same network interface names
  2. there's a reboot when changing between environments
  3. daemon processes don't access the database files at the same time
  4. database file owners match

As in your case a dual boot is in question, these limitations shouldn't be a problem, assuming the network interface names match.

The database directory needs to be moved to a location that's accessible by both environments. In the configuration file /etc/vnstat.conf the correct keyword to look for is DatabaseDir. With ntfs in question, you may also want to disable UseFileLocking and CheckDiskSpace to avoid surprises. It would likely also help to disable CreateDirs and UpdateFileOwner. Note that the mount needs to be available before the vnStat daemon is started.

Edits of the configuration file require a restart or reload of the daemon. It's also better to keep the daemon stopped when making a copy of the database directory. You'll also need to sync the configuration file changes to both environments after changed.

Bonus

In theory, that could be possible. I'd assume it should be possible to get the vnstat command working in Windows Subsystem for Linux. Once that works then it's possible to use the --exportdb functionality to dump content of the database to an ascii file, then add the collected data to the existing numbers (which may not exactly be straightforward) and then use --importdb to import back the changes and overwrite the existing database.

The possibly easier alternative would be to use vnStat 2.0 in both environments. That would result in having a sqlite database containing the data and I'd assume there are Windows tools available for manipulating the existing data. This option would require less steps but however still requires some dealing with the way vnStat stores the data in the database.