Filterdns stops working
-
ok, deleted 9.9.9.9 and 127.0.0.1 from dns server settings.
i have configured unbound in forwarding mode.
the resolver.log doesnt show anything suspicious. the entries where name couldnt be resolved are already removed from all aliases (they were just old entries).
i will try changing the debug-level and see what is beeing logged, thx for the tip.i will also reboot the pfsense tomorrow, then i hopefully only have 1 instance of filterdns running.
-
There can be several different filter DNS processes running legitimately. There can be one for aliases and one for IPsec endpoints that must be resolved, for instance. There might be others.
ps axww | grep filterdns
should show them. That should also show the different config files they are using, etc.
-
As IPsec-endpoints he have IPs, so that wont need filterdns.
According to the ps axww all processes use the same config file (/var/etc/filterdns.conf) and the same .pid-file.
I guess that are instances that i manually started to make the name resolution for aliases work again. -
ok, after the restart of the pf i only have one filterdns-process running and the names are resolved correct.
lets hope it stays this way :) -
i have the same problem. after several days, filterdns stopped working. just a reboot of the pfsense solve the problem for the next few days.
i just have 5 fqdn (dynamic dns) entrys in my ip alias table.(2.4.2 p1)
-
this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.![2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png](/public/imported_attachments/1/2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png)
![2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png_thumb](/public/imported_attachments/1/2018-01-06 13_14_43-pfSenseStatus_ System Logs_ System_ DNS Resolver.png_thumb) -
I have the exact same issue on 2.4.2-RELEASE-p1. I really hope someone finds a fix to this issue.
maybe the cronjob is what i need for now?
-
this is annoying, it happened again this night. yesterday after 11pm no more updates.
for the moment i will add a cronjob to restart filterdns every hour.Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.
-
Can you share your cron job with me? I'm not that familiar with cronjob's and i have the same issue. would like a temp fix for now until they fix the bug.
sure….
look at the picture belowContent of cron_filterdns.sh
#!/bin/sh pkill filterdns /usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 240 -c /var/etc/filterdns.conf -d 1
![2018-01-10 12_12_26-Services_ Cron_ Edit.png](/public/imported_attachments/1/2018-01-10 12_12_26-Services_ Cron_ Edit.png)
![2018-01-10 12_12_26-Services_ Cron_ Edit.png_thumb](/public/imported_attachments/1/2018-01-10 12_12_26-Services_ Cron_ Edit.png_thumb) -
When the problem happens, does /var/run/filterdns.pid contain a valid PID for filterdns? (Check the "ps uxaww" output to find the filterdns pid)
If you do "killall -HUP filterdns" do the entries resolve again, or are they still missing?
The code in place now tries not to restart filterdns unless it absolutely has to, but perhaps there is some issue when it's running for prolonged periods were it gets confused or fails to update when expected.
-
i will disable my cronjob and give you feedback when it happens again @jimp
-
a little update from me:
after the reboot 8 days ago everything still works (with the modification of the aliases). -
and again, no more update after 11pm.
"killall -HUP filterdns" has no effect at all.
-
ok, problem is back on my system :'(
When the problem happens, does /var/run/filterdns.pid contain a valid PID for filterdns? (Check the "ps uxaww" output to find the filterdns pid)
yes, its the pid of the running filterdns-process.
If you do "killall -HUP filterdns" do the entries resolve again, or are they still missing?
it doesnt change anything on my machine.
one thing changed:
the old entries were not deleted this time. but they are not updated.
new entries are not resolved but they are added to the filterdns.conf.also the mentioned cron-job from m0nji doesnt seem to be a good idea, since the "pkill filterdns" doesn't end the filterdns-process (at least not on my pf). that means only more and more instances of filterdns will start.
is there any way to really kill that process so i can start a fresh instance?
-
I have the same problem!
No filterDNS in the system->DNS Resolver logs after a week or some days. -
Somebody with a solution?
-
not really a solution, only a workaround:
run "killall -9 filterdns" in the shell and then "/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1" (or save and apply an existing alias). you could also put them in a cron as already mentioned.since the error happened to me again, i checked the resolver.log again to see if there is any information what the reason could be. even with debug level 3 there is no clue.
the last working entries are some normal adding and clearing entries and some information about some static entries.
the next time filterdns should run, it starts with a "Received signal Hangup(1)" entry and only one entry gets deleted and the static entries are listed.
after that every time filterdns should run (automatically or after a manual save&apply of an alias), only the hangup-message is in log.ps: seems this thread is about the same problem. maybe both threads should be merged.
-
I can confirm, same issue is happening with me. It seems to be it, it started happening after pfSense upgrade in Sept-Nov 2017. I am using development snapshot from 10th of January, issue still persists.
am using Policy Based Routing (PBR) and heavily rely on a lot of aliases: it took time to realize that tables of IP addresses (referring hostname based aliases) are not updated.
So temporary workaround so far is same, what you have suggested:
killall -9 filterdns
rm /var/pid/filterdns.pid (not sure if it correct path, just writing from my head)and then start filterdns process again (or refresh aliases).
In fact, starting filterdns (with proper arguments) sometimes did not help, I had to kill the process again and refresh (edit-save-apply) one of aliases lists.
-
Do we have any reliable and predictable way to trigger this issue? Any specific alias contents that cause it? Is there a set interval at which the problem occurs? Is there some other event that causes it to fail?
-
I'm not having any issue with filterdns, but I'm using it, it resolves a couple of (very static) URL's to IPv4 and IPv6.
When you guys kill filterdns, restart it like this :
/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 240 -c /var/etc/filterdns.conf -d 7
or even
/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 240 -c /var/etc/filterdns.conf -d 7 -f
"-d 7" will produce massive logging is the DNS log. Something might show up.
"-f" will keep it in the foreground, so keep your console access open for the time being. Ctrl-C will end it.Try also chancing the interval "-i 240" (4 minutes) to "i -600" (every 10 minutes) to give it more time.
Btw : "filterdns" is a pretty simple FreeBSD package (program), you'll find it here : https://github.com/pfsense/FreeBSD-ports/blob/devel/net/filterdns/files/filterdns.c
It doesn't do much, and it depends on one important thing : DNS should be working.
Also, it injects modifications into pf tables.
Knowing that all spawned threads (as many as there are tables) are relaunched every "-i xxx" seconds at the same time, is it possible that "pf " gets "overrun" ?