Frequent unbound restarts
-
@jwt Sorry, I don't follow.
Are you referencing the wireguard fiasco? Or was there some other news that put this into an updated context? An unbound regression in OpnSense 21.1.5?
On WireGuard, AFAIK OpnSense has a userspace daemon similar to what pfSense has offered for a while, not the in-kernel implementation that was apparently borked and then yanked.
EDIT:
Are you referring to this OpnSense forum post? I think that's isolated as that user had other problems when upgrading w/ unsupported packages (not to say unbound is unsupported, just that theirs seems like a complicated configuration).To be fair I did suffer from some constant unbound restarts on my own OpnSense box yesterday, but I haven't updated that machine from 21.1.4 to 21.1.5 yet so I'm 99% sure that was down to my toggling the ramdisk option for /var and losing unbound data at reboot. (I had read the option as /var/log ramdisk, which I assumed would have no ill effects. The /var option not so much since it encompasses so much more.)
-
Is there any news on this?
-
@sotirone still broken.
-
... or, if you have a couple of minutes :
Create Static DHCP MAC leases for every device you need to know by name and IPv4.
When done; do the magic click in the Unbound resolver settings page, then Save & Apply, and you just unbroke the issue. -
- https://redmine.pfsense.org/issues/5413 (unfixed in 2.6.0)
- https://redmine.pfsense.org/issues/12613 (unfixed in 2.6.0, unless you apply the patch manually)
- https://redmine.pfsense.org/issues/12612 (unfixed in 2.6.0, unless you apply the patch manually)
Both patches are half-assed workarounds. Sorry for the harsh words, but it is what it is.
-
I didn't say the issue(s) do not exist.
I highlighted a workaround. And no need to undo it when things get sorted out.Btw : when IPv6 takes over, static MAC DHCP becomes even more important.
Issue 12613 : wasn't aware of this one. My main switches, as pfSense, are fed by an UPS. And no one is ripping out cables here.
Issue 12612 : my pfSense uses DHCP on it's WAN interface. But guess what ?! I gave it a static DHCP MAC lease, set up in the OSP router"s settings.
Anyway, both 12613 and 12612 have a click solution now ;) -
@gertjan
rc.newwanipevents also happen when you power cycle devices connected directly to a LAN interface:/rc.newwanip: rc.newwanip: on (IP address: 192.168.120.30) (interface: LAN[lan]) (real interface: igb1).Anyway, both 12613 and 12612 have a click solution now ;)
Yes, one that force restarts Unbound, which is the topic of this thread. ;)
-
Not the topic, I know, but :
@thiasaef said in Frequent unbound restarts:
/rc.newwanip: rc.newwanip: on (IP address: 192.168.120.30) (interface: LAN[lan]) (real interface: igb1).
A rc.newWANip IP event on a LAN interface ?
The WAN is called LAN here ?
ok ....
Something else ?The the WAN or whatever LAN/OPT/... NIC receives a LINK DOW / LINK UP event, the attached processes have to restart to take into account the new system configuration. That's somewhat logic, right ? And badly enough, that's how unbound is works.
As said earlier, maybe I'm just lucky here, as all implied devices, ISP router, pfSense, switches, are using an UPS so power isn't an issue. So no "LINK DOW / LINK UP" for me. -
@gertjan the name of the event is simply misleading. Read https://redmine.pfsense.org/issues/12612 carefully and you will see that I am correct.
the attached processes have to restart
Only if you do not implement it properly. Unbound did not need to be restarted on 2.4.5-p1 with the exact same configuration and it also does not need to be restarted in such a case if you install it on Linux and apply the same configuration there.
So no "LINK DOW / LINK UP" for me.
It's fine that you don't care about the bug, but trying to convince me that link downs on the LAN side are something that shouldn't happen is going nowhere.
-
@thiasaef I do care. But I'm human, so I care probably a bit more about issues that impact my own installation.
The question exists on the https://www.nlnetlabs.nl support forum to implement the hardware event directly in the unbound process, like bind (named) : no more restarts, interfaces that come and go are dynamically are updated by the the process** itself. Netgate can't (or won't) rewrite unbound for that. And they really can't replace unbound for bind as then they would have to 'support' the entire thing (bind=huge as it is also a domain name server etc)
** if this is even possible. FreeBSD is used here, and known to be pretty secure. Hardware network events can an impact on the system configuration and is thus security related.
If would be a big deal if a WAN interface get attached as a LAN type.
So, the final decision is pushed out of the kernel, to the 'user' - the admin. The admin can decide to keep the interfaces up == no more events.
This is me thinking out loud.Btw : I'm like you : just another pfSense user.
Anyway : the subject is "Frequent unbound restarts ".
Issue 12613 has a patch.
Issue 12612 has a patch.
Issue 5413 is ongoing, so I dealt with it 'my way'.
The first post from myself about this "5413" issue are dating from 2016 (?), when Netgate/pfSense switched from DNSmasq to unbound. All my networks are small - 50 devices @max that I have to know by name and IP, so I "Static MACced" them all, and disable DHCP Registration.
The latest pfBlocker-devel release also call for this measure :
and I repeat : disabling this option will stop unbound from being restarted because of DHCP LAN events.
Some solutions have been proposed here : https://redmine.pfsense.org/issues/5413 but, IMHO, one is missing : a python 'DHCP-leases' scripts that reads the DHCP leases file. And also checks the time stamp of the DHCP-leases file, and read it again if a lease was added, disappeared, or got changed. Even with several thousands of DHCP leases, this file will not grow indefinitely (the number of leases is always a known max range).
This python script should also rewrite the /etc/hosts file - as unbound reads it upon restart.I know it would work, as the entire DNSBL is now based on a python script unbound extension.
It would be a great if some one could find a better solution as what is currently in place :
https://github.com/pfsense/FreeBSD-ports/blob/devel/sysutils/dhcpleases/files/dhcpleases.c line 604 : kill (HUP) unbound upon a DHCP server event.
I'm a (former) 'c' man myself, I can read Python but don't feel up to even experiment with it.
-
Netgate can't (or won't) rewrite unbound for that.
I agree and I would not whine about it if a) 2.4.5-p1 was suffering from the same issue (which it did not) or if b) it would not work on Linux either (which it does).
I'm a (former) 'c' man myself
Me too, which is why I can smell half-assed bug fixes from miles away.
-
@thiasaef said in Frequent unbound restarts:
Netgate can't (or won't) rewrite unbound for that.
I agree and I would not whine about it if a) 2.4.5-p1 was suffering from the same issue (which it did not) or if b) it would not work on Linux either (which it does).
Six months ago, I installed pfSense. It seemed pretty solid and for a time, I was a happy camper. And then, I discovered the DHCP lease DNS registration option and the ad blocker. I was so happy because it solved all my problems with having to configure clients manually and it comes in very handy as I have a habit of changing my VM's around on Proxmox all the time. Of course, I started experiencing these mysterious lengthy DNS resolutions and drove me nuts for months.
I call BS on Netgate having to fix Unbound. Last week, I got fed up with it and made the jump to OPNsense. I configured it with the same exact checkbox for DHCP lease DNS registrations and... it doesn't affect Unbound. It doesn't constantly restart and DNS resolutions are now rock solid (no more waiting for 30+ seconds every so often). Clearly, they're doing something right and someone can correct me, but I doubt they're maintaining their own version of Unbound.
I'm a (former) 'c' man myself
Me too, which is why I can smell half-assed bug fixes from miles away.
The fact that this bug has been open since 2017 with no end in sight quite possibly drove me away from pfSense for good.
