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.

WinEunuuchs2Unix
  • 102,282

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.

Teemu Toivola
  • 624
  • Awesome answer thank you. I'll update hopefully next weekend with triple boot results. The shared partition will be /mnt/e accessible by all three distributions. The only question will be if vnstat damoen only sees WSL traffic or Windows 10 traffic as well. – WinEunuuchs2Unix May 13 '18 at 20:53
  • Spent a great deal of time with ntfs-g permissions in /etc/fstab tying into clone in /mnt/e/var/lib/vnstat. In the end I did get it working but ../vnstat/* files have changed from owner:group vnstat:vnstat to root:root. So far so good but should I expect problems? --export from 18.04 (small data set) and --import to 16.04 (main db) I've written off as too complicated for cost/benefit. I'd like to learn more about SQLite and version 2.0. Last comment I read from Aug 2017 said it wasn't ready for prime-time. Is there newer stuff I can read? – WinEunuuchs2Unix May 20 '18 at 18:48
  • If you have vnstatd running as the vnstat user then you have to ensure that the user has write access to the database directory. If only root can write files in the directory then you'll have to run vnstatd as root if changing directory permissions isn't possible. – Teemu Toivola May 21 '18 at 20:52
  • Version 2.0 can be found from https://github.com/vergoh/vnstat where the bottom part of README.md documents the current development status. See also the CHANGES file as it lists the changes compared the previous version in a more compact format. Beta4 is already stable for use. Remaining changes are likely to only be usability and documentation related if no problems get identified. – Teemu Toivola May 21 '18 at 20:57
  • I finally managed to get all files owned by vnstat however only Ubuntu 16.04 kernel 4.14.42 vnstat 1.13 can update NTFS /mnt/e/var/lib/vnstat/.* backup files. Ubuntu 18.04 kernel 4.15.0-20 vnstat 1.18 gets error message can't create or delete the two .backup files and holding data in cache instead. On my phone so don't have exact error message. I tried rebooting 18.04 using kernel 4.14.34 but error persisted. My next experiment was to apt pin vnstat to version 1.13 in Ubuntu 18.04. – WinEunuuchs2Unix May 21 '18 at 21:04
  • So the problem was Ubuntu 18.04 had to be downgraded to vnstat/xenial. Perhaps because the data files are in 1.13 format? shrugs. Anyway both distros now update ntfs data on /mnt/e/var/lib/vnstat/* properly. I'm eager to check out Version 2 on Windows 10 WSL using a copy of /mnt/e/var/lib/vnstat/* soon. Thanks for the link and the great works you are doing. – WinEunuuchs2Unix May 21 '18 at 22:54