vnstat not updating

[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.

[CwF]

Sorry not trying to piss you off. Then again, it's not me it's not working for. I did not explain the cleanest way, I attempted a sure fire way. Sorry it didn't work out bubs.
I changed an interior usb cable 43 days ago, that's when I rebooted.

[morgon]

You did piss me off by quoting things I did not post and suggesting a ridiculous reboot.

But anyway thanks for trying to help.

vnstat seems to be rather delicate and I hate that for utilities.

At the very least I expect some helpful error message, but even that seems to be too much to ask from this piece of wonderful software.

But whatever.

[debiman]

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

please refer to this thread: viewtopic.php?f=5&t=138783
i know stable is stable, but refusing to upgrade 1614 packages is asking for trouble rather than preventing it.

fwiw, the old network interface naming can be re-enabled by adding "net.ifnames=0" to the kernel command line.