vnstat not updating

[morgon]

Hi,

(again I think) I am having problems getting vnstat to work.

My box is connected via ethernet to my router (my interface is enp2s0).

I have installed vnstat via aptitude and changed the default interface in the config-file (/etc/vnstat.conf) to that interface (Interface "enp2s0").

Then I created the databases via some incantation I cannot remember but I have a enp2s0 and a .enp2s0 file in /var/lib/vnstat, both owned by vnstat:vnstat.

There is a process (owned by vnstat) that showes up as "/usr/sbin/vnstatd -n" in ps.

However the data reported never changes.

It only seems to get updated when I run "sudo vnstat -u" in a terminal, but I want vnstatd to update it automatically...

Can anybody help me get this to work (I remember vaguely that I have done battle with vnstat in the past)?

Many thanks!

[CwF]

I've had that problem with extra ports, 2 and 3, when the first found port is disconnected. My note says delete and create the problem port, and maybe delete the first port if vnsat thinks there is one. Is there a enp1s0?

Code: Select all

vnstat -i enp2s0 --delete
vnstat --create -i enp2s0

[sunrat]

I've had the same problem. That seems to have fixed it.

[morgon]

thanks for the reply.

No, there is no enp1s0, I really don't understand the new logic of naming interfaces...

And your recipe unfortunately did not work for me.

I tried and re-recreated the databases and restarted the service, after which vnstat reported "enp2s0: Not enough data available yet.".

So I watched an youtube-video after which vnstat still reported "Not enough data available yet".

So I ran "sudo vnstat -u", after which vnstat now reports ridiculous volumes (13.4 GB received today).

And the fundamental problem that even with a running vnstatd the statistics never seem to get updated remains.

I must say I am getting tired of this...

Is there any alternative to vnstat?

[CwF]

If things are otherwise working, I'd first uninstall vnstat, reboot, reinstall, then take note of the response from vnstat with no switches and see what it says.
You could try to create the file /etc/network/interfaces.d/eth0.conf

Code: Select all

# eth0 = enp2s0
allow-hotplug enp2s0
iface enp2s0 inet dhcp

then reboot and see what vnsat alone says, then add/delete as before. I'd usually use a root terminal rather than sudo, not sure it matters.

The renaming can be changed, but I'd remind myself the system is otherwise working.
You could try /etc/udev/rules.d/70-persistent-net.rules where you can call out MAC's to name yourself, but that's not future proof and asking for trouble. Try to deal with the persistent naming as is. I've stopped renaming since errors there will stop a boot.

[sunrat]

I had to run slightly different commands:

Code: Select all

# vnstat -i wlan0 --delete --force
# vnstat --create -i wlan0
$ systemctl restart vnstat.service

It probably won't do anything until you restart the service.
I renamed the wireless interface ages ago but that should be irrelevant to this issue, as long as you have the active interface specified.

[morgon]

I did this:

Code: Select all

sudo systemctl stop vnstat.service
sudo vnstat -i enp2s0 --delete --force
sudo vnstat -i enp2s0 --create
sudo chown vnstat:vnstat /var/lib/vnstat
sudo chown vnstat:vnstat /var/lib/vnstat/enp2s0
sudo systemctl start vnstat.service

I have now a running /usr/sbin/vnstatd process, but the database never gets updated.

If I stop the service and run "sudo /usr/sbin/vnstatd -D -n" from a terminal it seems to work ok (the database gets updated) but it reports ridiculous usage numbers at first (14 GB received today).

What I have is a new internet-connection that is A LOT faster than anything I ever had (400 MBit/s) - could this be part of the problem (data arriving too fast for vnstat to handle it or overflowing some data-structure or whatever?)

[bw123]

What about totally purging and reinstalling, and let vnstat create the interfaces on first run?

from man vnstatd:

By default, if no databases are found, new databases
will be created during startup for all available interfaces excluding pseudo
interfaces lo, lo0 and sit0.

[morgon]

I tried.

sudo aptitude purge vnstat
sudo aptitude install vnstat

after that /var/lib/vnstat is empty.

vnstat reports "No database found. Nothing to do."

After "sudo systemctl restart vnstat.service" no vnstatd running.

I've come to hate vnstat.

UPDATE:

I've just noticed that after the purge and the re-install /etc/vnstat.conf contains the line "Interface eth0" - eth0 is an interface that does not even exist - is that a bug in the packag?

[bw123]

I tried.

sudo aptitude purge vnstat
sudo aptitude install vnstat

after that /var/lib/vnstat is empty.
...

That is weird I get this:

Code: Select all

# apt purge vnstat
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libgd3 linux-image-4.9.0-7-amd64
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  vnstat* vnstati*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 376 kB disk space will be freed.
Do you want to continue? [Y/n]     
(Reading database ... 139562 files and directories currently installed.)
Removing vnstati (1.15-2) ...
Removing vnstat (1.15-2) ...
Processing triggers for man-db (2.7.6.1-2) ...
(Reading database ... 139542 files and directories currently installed.)
Purging configuration files for vnstat (1.15-2) ...
dpkg: warning: while removing vnstat, directory '/var/lib/vnstat' not empty so not removed
Processing triggers for systemd (232-25+deb9u4) ...

and the database files are still present in /var/lib/vnstat

The man page for vnstat.conf says that the interface line is the default chosen when none is specified.

[arzgi]

Hardly a bug. Default value, which is quite common, can be changed.

[bw123]

I'm guessing this issue is on testing/sid or some other contraption?

[CwF]

l /etc/vnstat.conf contains the line "Interface eth0" - eth0 is an interface that does not even exist - is that a bug in the packag?

This is what I poorly explain, see above.

I meant after reinstall, you see the eth0 as I expected, delete it at the command line and add the correct named port. Don't modify that file, or look at it. Ask and answer at the command line.

[morgon]

I don't quite understand.

As mentioned above I did previously change the entry in the config-file to reflect the interface I want and could not get it to work.

What exactly do you mean by "Ask and answer on the command line"?

And what I mean is that eth0 does no longer exist by default - therefore it hardly makes a good default value...

[CwF]

I mean don't concern yourself with the contents of file, permisions and the like...use vnstat at the command line start to finish.

After the reinstall, in a terminal "vnstat" with no switches or arguements to see if it gives any feedback on an empty eth0 database. This I can't remember and have nothing to test it on.

So, my note says delete eth0, perhaps a default that gets in the way, can't remember?

Then add the correct interface, and restart the service or reboot.

The concept is at default it will work with eth0 without configuration, ONLY eth0. From there regardless of the names you need to add them.

On the fresh install I would issue the delete command for eth0 regardless, if it fails no worry...
Next step install correct interface.

I skipped the pretty code boxes, they're already posted...

Others might have an opinion or recommendation on sudo, I'm pretty sure I would do all this in a root terminal.

[morgon]

This is all very vague...

I ran vnstat, it tells me to create the database, I did, now I am back at the state where i have a running vnstatd but vnstat tells me "not enough data".

I have not changed anything to /etc/vnstat.conf. Update Interval is 30 sec. But even after 30 sec the database-files don't seem to get touched. They still have their old timestamp.

I will wait a little longer, but I expect that even tomorrow I will simply get "not enough data":...

This is evidently utter crap software.

Can someone point me to an alternative?

[bw123]

The default saveinterval on stretch is 5 min, you never did say whet ver you are using? I don;t find it crap at all, it's been pretty reliable and troublefree for a long time.

Code: Select all

$ grep -iB1 saveinterval /etc/vnstat.conf
# how often (in minutes) data is saved to file                                                        
SaveInterval 5                                                                                        
--                                                                                                               
# how often (in minutes) data is saved when all interface are offline                                            
OfflineSaveInterval 30 

Can someone point me to an alternative?

I don't believe there is anything so tiny, unobtrusive, self-contained, reliable and configurable anywhere else in the known universe.

[CwF]

I don't know of any better alternative. I tried to help since I've seen this exact issue but awhile ago. So it does happen in Stable. Understand vnstat is old and functional, and older than 'consistent persistant naming'. So I explained eth0 as the default.

from the top
1. Purge AGAIN

the database files are still present in /var/lib/vnstat

2. Then delete the files yourself. If you modified them manually then the files are yours, not vnstat's, so delete YOUR files.
3. REBOOT, sure you shouldn't have to, do it anyway.
4. Reinstall vnstat
5. Open a ROOT terminal

Code: Select all

vnstat -i eth0 --delete

Code: Select all

vnstat --create -i enp2s0

6. REBOOT...

Then stop fiddling with things, use as normal for a few hours, and in a terminal "vnstat" all by itself and see what it says.

We are not qualified to call it crap, it obviously works:

Code: Select all

~/Desktop$ vnstat

                      rx      /      tx      /     total    /   estimated
 eno2:
       Sep '18    252.94 GiB  /  174.22 GiB  /  427.16 GiB
       Oct '18     37.46 GiB  /   24.79 GiB  /   62.25 GiB  /  334.93 GiB
     yesterday      7.18 GiB  /    4.41 GiB  /   11.58 GiB
         today      2.21 GiB  /    1.21 GiB  /    3.42 GiB  /    7.29 GiB

 eno1:
       Sep '18      2.98 GiB  /  655.13 MiB  /    3.62 GiB
       Oct '18    574.75 MiB  /  103.26 MiB  /  678.00 MiB  /    3.56 GiB
     yesterday     71.40 MiB  /   17.79 MiB  /   89.19 MiB
         today     63.14 MiB  /    8.22 MiB  /   71.35 MiB  /     151 MiB

[CwF]

I'm going to add the reason it's mucked up is the OP manually edited files and inadvertently change the ownership. So that blew up the last attempt.

REITERATE: Use a terminal, my preference a ROOT terminal using vnstat cli. DO NOT EDIT FILES! That's what the cli facility is there for, it writes the files.

[morgon]

the OP manually edited files and inadvertently change the ownership. So that blew up the last attempt.

Not true at all. Read my posts.

And note that this "the database files are still present in /var/lib/vnstat" was not posted by me.

I did edit files in the beginning - but I changed only the interface and the update interval.

And I changed the owership of the files only because I was running the creation command via sudo, so the resulting files were owned by root. I only corrected that.

Nothing I did explains the behaviour that I see.

I am running vnstat 1.18-2 and I am getting tired of this crap, so for the time being I give up on it. Getting told to reboot (!!!) is simply ridiculous.

Yes vnstat is great when it works, but it is a nightmare when it doesn't (I've had problems with it in the past), and that is my definition of crap.