Vnstatd no longer starts

[xPliZit_xs]

Hi,

since version 21.1.2 and .3 my installed vnstatd does not automatically start after rebooting my machine or manually through GUI not working either. Syslog shows: root[81118]   /usr/local/etc/rc.d/vnstat: WARNING: failed to start vnstat

Only work around i have found is to go into the shell and execute: vnstatd -d.
It was working when i installed it at version 21.1.1

Thanks, maybe somebody can look into this.

[Ricardo]

1) What happens if you try to reset the vnstat database:
Services/Vnstat/General tab : at the bottom of the page there is a Reset button.

2) Do you use TMPFS (a.k.a Memory Filesystem or otherwise known as Ramdisk) for your /var partition ?

[xPliZit_xs]

Will have to check to reset the db at the end of the month since i was actually measuring my traffic.

I do use TMPFS yes.

[Ricardo]

If you use TMPFS for /var, your WAN is PPPoE, this is some "known" defect with vnstat since approx. 2yrs.

https://github.com/opnsense/plugins/issues/1264
https://github.com/opnsense/plugins/issues/1061

[iso7]

I ran into this issue today, and after a device restart the vnstat service failed to load.  The error given in the log was related to the vnstat db file being inaccessible.  It looks like there is some inconsistency between the package default intended behaviour (storing the db file outside of the /var folder), vs the "reset database" button (which forces a new file to be written into the /var/lib/vnstat folder).

I've noticed that at some point, the vnstat package created this link on my OPNsense appliance (which is configured to use MFS for /var and /tmp):

Code: [Select]

/var/lib/vnstat -> /root/var/lib/vnstat

I assume this is to work around the volatile nature of var when using MFS (ram) for storage.  The issue seems to be that the target of this link isn't accessible by the vnstat user.  As a result, it can't create the db in there or read any existing db file. 

Hitting "reset database" works temporarily, as this removes the link again and stores the db in the MFS folder structure, but then it's lost again as soon as a reboot occurs.

A permanent workaround seems to be changing the owner of the /root/var/lib/vnstat folder using:

Code: [Select]

chown -R vnstat:vnstat /root/var/lib/vnstat
After doing this, the service can be started up, and it will create the vnstat database in there.  This survives reboots I think.

[Ricardo]

If you put this into a github ticket, everyone would benefit from your observation.