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 about 1 year 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 about 1 year 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 about 1 year 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 about 1 year ago
This limitation is documented here:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/filterdns-thread-errors.html
Updated by Dark Baritone 11 months ago
I also ran into this issue. I had to bump my threads past 4096 to get it to work properly. A message on the "Tables" page and/or the "Alias" page when filterdns crashes along with the reason would be very helpful here. https://forum.netgate.com/topic/195791/alias-entries-are-not-being-added-to-the-tables-even-hardcoded-ips
Updated by Patch Public 1 day ago
To the user this bug results in latent failure of a pfsense installation so is more serious than it initially appears.
To explain in practice a user will- gradually develop a configuration
- At sometime exceed this limit, at which time all pre-existing alias definitions will be maintained however only the new change will not be fully implemented in the alias tables and filtering. A user is unlikely to notice if the update is part of routine maintenance.
- At a later time pfsense will be restarted. At which time all the aliases are rebuilt and completely different alias creation errors occurs resulting in an obscure system failure.
This thread rediscovers this issue https://forum.netgate.com/post/1229869