If I include this it looks like there is a config path hardcoded into this page file, i wouldnt want to do that as it could then conflict with that plugin if installed.... Suggestions??
New version release 2018.10.10 this reverts to the old path to store the vnstat db(/var/lib/vnstat) that will not persist across reboots. This should solve any of the unintended issues i have cause with peoples unRaid setups. I'll work on a future release to copy the vnstat db in/out of memory and will utilize emhttp events on when to do this, and not impact array functions.
Alright I just release a new version that reverts to using the default database path (/var/lib/vnstat), that will not be persistent across reboots. This should remove my "bad mark" as well as fix any problems people with having with array shares not being visible or stopping array from stopping. I will work on another version that will listen for the events and utilize those to copy the db in/out of memory.
Excellent, thank you for pointing this out. This helps in coming up with a fix on this. I appreciate this. I will add event scripts for array start and stop and not create the location inside /mnt/user/ until after the array has started.
I am working on the issues called out in plugin support thread however I has been stated by several people that they do not believe it is my plugin causing the issues noted in this thread.
Yes, what I am asking though is your system using eth0, or do you utilize a non standard port. Right now I filter the list display so that it only displays interfaces that contain eth, bond or br
Ok yeah it’s very possible the issues found over the weekend resolved that. But again, none of the people I worked with over the weekend had these issues.
No need to copy it to memory if the filesystem gets created properly. I've release version 2018.10.07d which corrects the pathing issues. Sometimes i was using ${DOCKER_APP_CONFIG_PATH}/networkstats and other times i was using ${DOCKER_APP_CONFIG_PATH}/vnstat. This has now been normalized.