Alias not updated
-
@sef1414 said in Alias not updated:
https://redmine.pfsense.org/issues/7209
Do your aliases have combinations of FQDNs and IPs? Is it always the same aliases that fail?
Do they contain FQDNSs that fail to resolve?
Best practice is to use separate aliases for IPs and FQDNs if you can.
Steve
-
Some of my aliases contain combos. The ones that are currently being affected are strictly FQDN aliases.
The FQDN's all resolve properly when I manually do a Filter Reload via the GUI.
I thought I could use /etc/rc.filter_configure as a cron job as a workaround, but running that command seemingly doesn't do anything. When I run that the system log shows
Jun 10 16:25:11 check_reload_status 308 Reloading filterbut nothing happens. So now I'm really stumped here.
Extra info:
When the problem originally began, I couldn't get aliases to resolve some FQDNs at all. I followed some advice from that bug report and added kern.threads.max_threads_per_proc = 4096 to the system tunables and that seemingly cleared that up.. though I don't believe I have a huge amount of aliases, and most of them are just IPs.
I changed the Aliases Hostnames Resolve Interval setting in the Advance settings page from 300 to 90 to see if that would improve things, but it doesn't seem to matter what that is set at.
-
Does it show filterdns errors when this happens? Can you see which fqdns are failing to resolve? Is it always the same ones?
Steve
-
Thanks for prodding me to dig deeper. I'm going to outline the steps I took as a layman in case anyone else is facing the same issue. I'm using Pfsense 2.6.0-RELEASE .
The GUI logs don't seem to be very verbose. System Logs show nothing besides "reloading filter" and the GUI logs when the filter is reloaded don't show any errors.
However, from the shell I was able to tail all the logs, it seems like the relevant ones are at /var/log/resolver.log
On a filter reload via shell command, it was displaying a "failed to resolve" error. I removed the offending FQDN, and had to repeat that step once more. Curiously, one of the two FQDNs failing to resolve resolve just fine when I ping it. But I'm going to ignore that for now, as I'd just like to get aliases properly updating.
So after removing those two hostnames that failed to resolve, I can now successfully reload the filter
/etc/rc.filter_configureCheck that there are no hostnames failing to resolve
[2.6.0-RELEASE][root@pfSense.localnet]/root: tail -f /var/log/resolver.log | grep "Failed"And my test alias shows an updated IP in the Diagnostics -> Tables section.
So I continued to tail those logs and pfsense does not seem to be updating the aliases automatically. I had the update interval set to 90s for testing, though after watching for 10 minutes I did not see anything come through on those logs and my test firewall alias was not updated.
I installed the Cron package and added an entry
*/1 * * * * root /etc/rc.filter_configureNow aliases are being updated automatically.
So pfsense should be updating the aliases automatically at the specified interval and it's not. I'm not sure why that is. I don't know if the command I'm using is effectively the same one that should be running in the background. I would be interested in a proper resolution, but for now I've at least got a workaround that will ensure my aliases are getting updated at a regular interval.
-
Interesting. You might try resolving one of those in Diag > DNS Lookup. Make sure all the defined DNS servers can resolve it. If you have one or more shown that can't that might explain intermittent failures. You might want to remove any that are failing.
Steve
-
Interestingly today the original "bug" (or not) made a re-appearance. I had an alias that was working fine. It contained a nested aliases, and that stopped showing up in the table.
I increased the kern.threads.max_threads_per_proc from 4096 to 8192, and it started working. I also saw a whole new slew of FQDNs failing to resolve.
Curious, do you have any insight on intended design here, or the functionality of that tunable parameter? I'm guessing its not intended for resolution of aliases to fail if any of them fail to resolve?
And none of the aliases that I've been having trouble with have contained FQDN's that failed to resolve, they offending FQDNs have been in other aliases.
I'm not sure why that system tunable improves the situation. It was a suggestion I just blindly followed from the bug report thread. And increasing it was just a shot in the dark. I'll have to do more research.. maybe the failed resolutions are causing timeouts which result in the rest of the filter reload failing?
Guess I'll keep any eye on things and see if the issues persist.
-
Hmm, indeed that sysctl is not specific to this issue. That fact that increasing it allows it to run implies you have a very large number of threads. I would guess filterdns is trying to resolve all the fqdns and some are getting stuck and hitting that bug. You can probably see that in the process list. How many FQDNs do you have in aliases, approximately?
Steve
-
Looks like a little less than 150 FQDNs.
-
Hmm, not that many then. I wouldn't expect anything special required there.
There anything unusual about the FQDNs that are failing?
-
I've removed most of them at this point. My work around was working.. for a while. Doesn't seem to be anymore though. At a loss as to what to try now.
-
How many do you have remaining?
Are they all failing? Failing randomly? Anything logged?
Steve
-
I have about 25 aliases containing a FQDN. Logs report that none of them are failing.
However, aliases simply wont update. I have one where I've tried a nested alias, or adding the IP directly, and it simply doesn't update. It's been over a week without it updating.
The strangest thing is in the logs I can see it appear to be added successfully (e.g. Adding Action: pf table: ......)
-
Hmm. Does it update if you reboot?
-
Planning to give that a try as soon as I can take everything offline. Will give you an update.
-
Reboot fixed it. Usually would be a go to but the last go around reboots did not have any effect.
-
Hmm, odd. I would have to guess some stuck process maybe?
-
Maybe.. weird that some updated aliases were working fine though.
