Feature Request: vnstat persistant stats

[unipacket1]

Per the discussion here https://forum.opnsense.org/index.php?topic=9503
would like to ask if it would be possible to add an option to save vnstat data between reboots.

[soder10]

If I am not mistaken, this is an issue only for /var logs stored on a tmpfs? Non-volatile /var will preserve the stats across reboot?

[mimugmail]

Yep ...

[mimugmail]

@fichtner adding _mfs to rc.conf template is enough?

[fichtner]

Yes, though it’s _var_mfs

…

On 15. Feb 2019, at 21:52, Michael ***@***.***> wrote: @fichtner adding _mfs to rc.conf template is enough? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[soder10]

May I ask what does "MFS installation" mean in this context?

[mimugmail]

/var in ramdisk

[fichtner]

MFS = memory file system The logic behind this change moves the statistics to permanent storage (root partition).

…

On 16. Feb 2019, at 08:42, Michael ***@***.***> wrote: /var in ramdisk — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[soder10]

Ah, ok so its Memory File System.

[soder10]

Am I mistaken, or this issue was closed as "not implemented" feature?

[fichtner]

Yes, you are mistaken.

[soder10]

Ok, in that case I am confused a little bit :) I run vnstat on MFS, and if I reboot the stats get cleared out. Even worse, the VNSTAT service breaks (cannot start) as long as I dont reset the database manually. Has to do something with igb vs ppoe interface binding during pppoe session establishment.

[fichtner]

Maybe the issue is back since vnstat 2.x, not sure.

…

On 4. Feb 2020, at 15:32, soder10 ***@***.***> wrote:  Ok, in that case I am confused a little bit :) I run vnstat on MFS, and if I reboot the stats get cleared out. Even worse, the VNSTAT service breaks (cannot start) as long as I dont reset the database manually. Has to do something with igb vs ppoe interface binding during pppoe session establishment. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[iso70x]

I ran into this issue, 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 to persist data across reboots), vs the "reset database" button (which forces a new file to be written into the /var/lib/vnstat folder that will be lost as soon as a reboot occurs).

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):

/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:

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 and the service starts without errors as well as showing historical stats even on VMS systems.

[soder10]

I ran into this issue, 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 to persist data across reboots), vs the "reset database" button (which forces a new file to be written into the /var/lib/vnstat folder that will be lost as soon as a reboot occurs).

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):

/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:

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 and the service starts without errors as well as showing historical stats even on VMS systems.

Thanks for the detailed description. I hope this gets fixed sometime now as the devs understand the scenario better.