Bug #1407
closedGUI is sluggish without working DNS
0%
Description
If you don't have functional DNS, the GUI can be extremely sluggish.
Common scenario to reproduce:- Multi-WAN setup where for whatever reason all DNS servers are going over the WAN that is down (in my case is was my cable provider handing out 8.8.8.8 as a DHCP DNS server when I had it set for a static route over DSL...)
- If the WAN with DNS is down, navigating the GUI is quite slow.
- Fix DNS and it's back to being speedy
Updated by Ermal Luçi over 13 years ago
- Status changed from New to Feedback
Can you try a snapshot from tomorrow.
I fixed #1410 and that would fix this as well.
Updated by Jim Pingle over 13 years ago
- Status changed from Feedback to New
That may help with multi-wan, but doesn't help the case when there is only one WAN, or all WANs are down.
Updated by Chris Buechler over 13 years ago
- Priority changed from Normal to High
still hit this and it creates major issues with trying to operate or troubleshoot the system when there's no Internet.
Updated by Ermal Luçi over 13 years ago
Can you check if /etc/resolv.conf has any entry during this time?
Updated by Chris Buechler over 13 years ago
resolv.conf was populated in this case.
This instance was exacerbated by AutoConfigBackup so it was even worse than usual. I'll create a separate ticket for that
Updated by Ermal Luçi over 13 years ago
Does it happen if resolv.conf has an entry
'options timeout:1'
'options attempts:1'
Updated by Ermal Luçi over 13 years ago
- Status changed from New to Feedback
Please test latest snapshots fixes have been pushed there.
Updated by Peter Baumann over 13 years ago
Hi all,
I just tested successfull with the following snapshot:
2.0-RC3 (amd64)
built on Mon Aug 15 22:32:41 EDT 2011
What I did:
- removed every dns server entry > webgui response is normal. disabled internet link so no dns server reachable -> webgui response is normal.
So, I think this is working now.
Peter
Updated by Ermal Luçi over 13 years ago
- Status changed from Feedback to Resolved
When having localhost as a first server in resolv.conf, as is done on latest snapshots, this bug does not manifest.
So basically this is related to the resolver library timeouts.
The workaround works for now and there are very rare occasions when a forwarder is not running on pfSense itself.