OPNsense Forum
English Forums => General Discussion => Topic started by: lox on July 19, 2019, 01:16:01 am
-
I have two instances installed and running the latest release.
Whenever it reboots unbound won't start.
"The command '/usr/local/sbin/unbound -c '/var/unbound/unbound.conf'' returned exit code '1', the output was '[1560960202] unbound[50455:0] error: can't bind socket: Can't assign requested address for fe80::5868:342b:b04d:bb1f port 53"
But "Register IPv6 link-local addresses" is disables as IPV6 in interfaces configuration is.
If I start it manually after reboot, it starts up properly.
I want to enable monit to monitor it and start it automatically when it fails, but I cannot find the shell command to start/stop it.
-
Bump
-
Bump
-
I've noticed this too. After an overnight shutdown (due to storms in the area), I started up my router and found Unbound didn't start. I was able to manually start Unbound so we could get connectivity. Is there any reason why it doesn't auto-start upon boot?
-
Here's the command:
/usr/local/sbin/pluginctl -s unbound start
you can change the 'start' to stop or restart.
I'm attaching a screenshot of my Monit config for Unbound.
-
Is fe80::5868:342b:b04d:bb1f on a PPPoE?
Cheers,
Franco
-
I'm also getting this issue. Put a bandaid on it as suggested with monit. When I search for the ip6 address I see it listed as link#11 and link#12 with Flags "UHS" and Use "0" under System:Routes:Status.
Anyway to figure out what this address is?
-
I have the same issue with these IPv6 bindings.
I dont use any IPv6 on my opnsense but unbound always tries to bind on a IPv6 address.
opnsense: /usr/local/etc/rc.bootup: The command '/usr/local/sbin/unbound -c '/var/unbound/unbound.conf'' returned exit code '1', the output was '[1571684608] unbound[58561:0] error: can't bind socket: Can't assign requested address for fe80::d468:38e9:5205:560a port 53 [1571684608] unbound[58561:0] fatal error: could not open ports'
Any ideas?
-
Do you have an OpenVPN instance running?
-
I have this problem too, and YES I have openvpn server running.
-
Can you try to only let it listen on LAN interface?
-
I do confirm. When openvpn server is set up for a single interface only, unbound starts on boot without issues.
-
I've got a similar issue with unbound not restarting and also running an OpenVPN server (where Unbound is set to listen to the LAN + OpenVPN interface). Were you able to solve this?
-
Exact same issue listening to LAN and VPN. I can start it from the GUI, but it would sure be nice if it could start itself.
-
Is there a solution for this?
When I reboot OpnSense, at some point all my devices are left with apparently no Internet access and it is just a DNS issue - because the Unbound DNS service is stopped.
-
Looking at the date of the last post and not having any data on 22.1.1 latest makes me wonder if there was a way to find out if it works better or not...
Cheers,
Franco
-
Actually, yesterday I updated my system at midday:
Type opnsense
Version 22.1.1_3
Architecture amd64
Flavour OpenSSL
Commit 6b667da6f
...
Updated on Mon Feb 21 14:49:37 UTC 2022
After the different reboots, I was losing Internet connection, but I knew what it was. I just had to login via the router IP (no DN) and re-run the Unbound DNS in the dashboard.
Losing DNS does not occur immediatelly. Tonight I went to sleep with Internet. Today I woke up and there was no Internet - again, the Unbound DNS was deactivated.
By the way, this is the same issue I had before, where I mistakenly though I lost connectivity, and then I discover it was only DNS:
https://forum.opnsense.org/index.php?topic=25947.msg125084#msg125084
Suricata also stops after a few minutes. But I cannot make it work, it always stop. On the contrary, DNS stays running if I do not reboot the router.
How can I research what is going on?
-
Are you using blocklists in Unbound with a Cron Job maybe?
Logs are always helpful...
Cheers,
Franco
-
Same issue here since I updated to 22.1.1_3 and yes I have the cron job which update the block lists every morning at 6:00 - so now after the update Unbound won't restart and I have to manually start it, any suggetsions?
Which log should I post?
Tia.
-
For one try:
# configctl unbound check
Logs are usually in system log, e.g.:
# opnsense-log
or resolver log for unbound:
# opnsense-log resolver
Cheers,
Franco
-
For one try:
# configctl unbound check
I get this:
error in configd communication %s, see syslog for details
And I've attached the message I found in the log
-
# service configd restart
# configctl unbound check
If configd isn't responding it could be anything really.
Cheers,
Franco
-
Perhaps time to plan for a fresh reinstall.
-
Health audit (under system: firmware: status) might be useful to spot potential problems that are easy to fix.
Cheers,
Franco
-
That seems all good
***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.1.1_3 (amd64/OpenSSL) at Thu Feb 24 18:48:26 GMT 2022
>>> Check installed kernel version
Version 22.1.1 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.1.1 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 65 dependencies to check.
Checking packages: ................................................................... done
***DONE***
-
Indeed, which means the issue could come back even after clean reinstall + configuration import. Which plugins are you using? Reminds me I wanted to add that to the health audit.
Cheers,
Franco
-
Does the Unbound 1.15.0 change log offer any new insights on the matter?
https://nlnetlabs.nl/projects/unbound/download/#unbound-1-15-0
miroco
-
Which plugins are you using? Reminds me I wanted to add that to the health audit.
os-dmidecode (installed)
os-smart (installed)
os-theme-cicada (installed)
os-wireguard (installed)
-
Doesn't look suspicious, sorry, unable to think of how to debug this further.
Cheers,
Franco