vnstatd error I have never seen before with recent update

[darthclide]

Expected Behavior

Router log should show typical dhcp requests and wan ping checking

Current Behavior

Out of nowhere, the log shows the following:

Possible Solution

Maybe I need to create this file so the errors go away? Or maybe I need to just do a wipe on the SD and start over again? (I hope not)

Steps to Reproduce the Problem

Just wait a few minutes after reboot.

Context (Environment)

So far it hasn't affected me, but it worries me that it is trying to write to a file that doesn't exist, or is malformed in some way.

Specifications

• OpenMPTCProuter version: .55
• OpenMPTCProuter VPS version: Version 0.1017 5.4.52-mptcp
• OpenMPTCProuter platform: RPI4 Model B Rev 1.1

[Ysurac]

It's the squashfs or ext4 image ?
Do you have any warning in OpenMPTCProuter status page ?
Can you give me the result of mount via SSH on the router ?
And can you check if the file /var/lib/vnstat/vnstat.db exist ? ls /var/lib/vnstat/ for example.
If the file exist rm /var/lib/vnstat/vnstat.db. In all case try a /etc/init.d/vnstat restart.

[darthclide]

It is ext4 image.
Hmm, under status there are multiple pages, which one do you want me to look at? "Overview"? I see no errors on that page.
Results of mount
/dev/root on / type ext4 (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=918496k,nr_inodes=229624,mode=7 55)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
cgroup on /sys/fs/cgroup type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset,cpu ,cpuacct,blkio,pids,rdma)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mmcblk0p1 on /boot type vfat (rw,noatime,fmask=0022,dmask=0022,codepage=437 ,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
mountd(pid5984) on /tmp/run/blockd type autofs (rw,relatime,fd=7,pgrp=1,timeout= 21474836510,minproto=5,maxproto=5,indirect)

Yes, the file does exist. I did the restart and immediately the log still shows:

Thu Aug 13 06:50:30 2020 daemon.info vnstatd[26244]: Error: Exec step failed (11: database disk image is malformed): "delete from fiveminute where date < datetime('now', '-48 hours', 'localtime')"
Thu Aug 13 06:50:30 2020 daemon.info vnstatd[26244]: Error: Database "/var/lib/vnstat/vnstat.db" cleanup failed: No such file or directory
Thu Aug 13 06:50:30 2020 daemon.info vnstatd[26244]: Exiting...

Extra info: My log is now spammed full of these messages before I even tried restarting vnstatd

[Ysurac]

Before the restart you did the rm ?
For the log, it's not related. You use RPI wifi ? this seems like a wrong config option.

[darthclide]

Ah, no I did not. I missed that part. May I ask why you want me to delete it? Wouldn't that ensure a restart will not work?

And my wifi is disabled (at least according to luci). May I ask which file I should put "dtoverlay=disable-wifi" into?
/boot/config.txt
/boot/distroconfig.txt

I have no idea how else to get it to stop spamming these messages since I do not use wifi on this pi.

[Ysurac]

The file seems to have a problem, after a vnstat restart it will be recreated.

You can try first to update RPI4 firmware if not already done: https://github.com/Ysurac/openmptcprouter/wiki/Update-RPI4-firmware

[darthclide]

That was my first thought about updating the firmware. And yes, it did upgrade to April 2020. But still no change. Could you tell me which config file I should put the command into before I restart the router?

[Ysurac]

In /boot/config.txt

[darthclide]

As a reference I came across this:
RPi-Distro/firmware-nonfree#8

It would seem the chip is notoriously broken all the time, and the only way around it is finding the right version that works and sticking to it. I know you don't heavily support the RPI4, but could you consider finding the most stable version and writing up a guide on how to change the brcmfmac driver safely and 0 conflicts with your OMR software?

[Ysurac]

bluetooth is disabled by default (in /boot/distroconfig.txt).
OpenMPTCProuter is based on OpenWrt and I use a RPI4 for most tests, I have no problem for now on latest release.
I don't know exactly why some have issues and others not...

[darthclide]

Hmmm, perhaps it is the revision then? Because I managed to get it working okay on my 1.3 model.

Also, after I did your commands, this is the result of ls -al

Do I need to restart the router? Why is it now changed to tmp?

[Ysurac]

/var was always a link to /tmp
You only need to restart vnstat.

[darthclide]

Okay, I did so. I will keep my eyes on the log to see if I get those errors again.

[darthclide]

Okay, while I haven't seen any more errors about vnstat, I did notice on the vnStat Graphs page it is only monitoring usb0 and usb1. Would a router restart fix this maybe?

Also this happened in the log. I am unsure if it is related or why it happened?

eth1 is my DSL plugged into Linksys USB-Ethernet adapter

[darthclide]

Extra info about the promiscuous mode messages:
It appears the spam of these messages happens at 1 hour intervals. Any ideas on why it is doing this? What is odd is that when I updated the OMR it automatically changed my eth1 to DHCP mode (it was on static). I tried changing ti back to static address, but this spam of message still arrived.

[Ysurac]

To detect multipath support on each interface tracebox is used, this set it in short promiscuous mode. The message is hidden in most case, but this message seems to come from realtek driver, I will hide it in next release.

[darthclide]

So the fact it spams so many is normal? I never saw it before, so may I ask what changes you made in this .55 release that have to do with this message?

[Ysurac]

Yes, it's not a problem and this doesn't change anything on perf.
The change is that tracebox is enabled again to check multipath.

[darthclide]

Ah okay. This post got side tracked so if you want to delete all these posts you can. But I think that github post about the chip might be helpful for those who are willing to dig and fix their RPI wifi problems.

[github-actions]

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days