Messages

1

21.7 Legacy Series / Re: Unbound service stopped after updating blacklists

« on: September 28, 2021, 12:54:23 pm »

UPDATE:
A restart of the router seems to of cleared things up on my OPNsense instance.  Errors that were appearing in event log related to swap and configctl are no longer occurring, and the DNS blocklist update ran this morning without any issues.  Unbound restarted cleanly during the task as expected.

I didn't restart the appliance after either of the previous 2 updates, so maybe that's related somehow.

2

21.7 Legacy Series / Re: Unbound service stopped after updating blacklists

« on: September 27, 2021, 04:25:29 pm »

I had the exact same thing happen.  Upgraded OPNsense yesterday (didn't reboot after upgrading).  First thing this morning unbound service was stopped.  It happened immediately after the DNS blocklist update task had run via the scheduled job.  Had to manually start unbound.

I'm going to reboot router this evening, as I've noticed a few other weird errors that have started to appear in the syslog since the upgrade (swap_pages_getswapspace and lots of configctl events), and will see whether it happens tomorrow.

3

21.1 Legacy Series / Re: Vnstatd no longer starts

« on: March 24, 2021, 03:29:19 pm »

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.