Bug #15708
open
The filterdns service won't start
0%
Description
If the filterdns.conf file contains more than 749 entries, the filterdns service will fail to start. This limitation applies regardless of whether the entries come from a single or multiple aliases.
When an alias includes both a hostname and IPs/subnets, the hostnames and IP entries are added to the filterdns.conf file. The ability to define a scope of IPs when specifying the host type Alias makes it relatively easy to trigger this behavior.
Here is an example of how to recreate this issue:
1. Define an Alias type Host(s), defining:
www.google.com
192.168.0.0-192.168.2.236
Save/Apply Changes
2. Navigate to the Diagnostics/Command Prompt and execute:
cat /var/etc/filterdns.conf | wc -l
You'll notice that there are 750 entries. (should be only one)
3. From the Diagnostics/Command Prompt, execute:
ps axww | grep filterdns
You'll notice that the filterdns service is not running.
4. Now navigate to the Alias defined in the first step and remove one entry (e.g 192.168.0.0).
Save and Apply the changes.
5. Repeat the step 2)
you'll notice that there are 749 entries
6. Repeat the step 3)
you'll notice that the filterdns service is running.
Updated by Lev Prokofev 4 months ago
- Status changed from New to Confirmed
I was able to replicate this on 24.03
As long as the list has >749 entries it fails to update.
Updated by Kris Phillips 3 months ago
Was able to recreate this with a customer. Was working fine on 23.09.1, but once they upgraded to 24.03 they were no longer able to use many of their rules.
Running "cat /var/etc/filterdns.conf | wc -l' revealed they had 2308 entries and only some tables updated. filterdns was not running properly.
Updated by Kristof Provost 3 months ago
I've reproduced this locally, and got this error message:
filterdns: could not start host thread for www744.sigsegv.be
filterdns starts a thread per entry, so it looks like we're running into a system limit more than a direct bug in filterdns (although arguably its design is a bug all by itself).
I've not found any evidence of that value changing in recent releases, so I'm a little surprised that this would be a regression rather than the customer increasing the number of entries.
Either way, they can work around the problem by setting `sysctl kern.threads.max_threads_per_proc=2500` either as a once-off on the CLI, or persistently on the system tuneable page (they'll want to have slightly more than twice the number of entries for filterdns).
The ultimate solution to this will be a redesign of filterdns, but the workaround will work on all releases.
Updated by Marcos M 2 months ago
This limitation is documented here:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html