So many filterdns instances…

eri--

I am working on cleaning those up.

phil.davis

I upgraded 1 system to:
2.1-BETA1 (i386)
built on Wed Jan 2 16:40:07 EST 2013
FreeBSD 8.3-RELEASE-p5

In the system log, every 5 minutes, is:

Jan  3 08:16:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:21:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:26:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:31:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:36:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:41:35 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:46:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:51:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 08:56:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 09:01:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 09:06:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  3 09:11:36 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known

/var/etc/filterdns.conf just has a list of dynDNS IP names that are used in an alias (actual names changed in the text below):

pf name-1.dyndns-ip.com INF_inet_ips
pf name-2.dyndns-ip.com INF_inet_ips
pf name-3.dyndns-ip.com INF_inet_ips
pf name-4.dyndns-ip.com INF_inet_ips
pf name-5.dyndns-ip.com INF_inet_ips
pf name-6.dyndns-ip.com INF_inet_ips
pf name-7.dyndns-ip.com INF_inet_ips
pf name-8.dyndns-ip.com INF_inet_ips
pf name-9.dyndns-ip.com INF_inet_ips
pf name-10.dyndns-ip.com INF_inet_ips
pf name-11.dyndns-ip.com INF_inet_ips

Systems on 31 Dec 2012 snapshots are not getting this in the system log.
I guess something in the recent filterdns code changes that Ermal is working on is processing a blank line somewhere?

eri--

Upgrade to today snapshot(Jan 3) it should be better maybe you caught a snap with intermediate changes.

Also if you run top -H you should see the hostnames on each tread run for them.

phil.davis

A later/Jan 3 snap is not up yet. I will upgrade and report back when Jan 3 snap appears.

phil.davis

2.1-BETA1 (i386)
built on Thu Jan 3 02:32:11 EST 2013
FreeBSD 8.3-RELEASE-p5
still has the same failed looking up "(null)" message every 5 minutes.
There is another snap up now 06:39 - I'll load that now and see…

phil.davis

2.1-BETA1 (i386)
built on Thu Jan 3 19:04:10 EST 2013
FreeBSD 8.3-RELEASE-p5

Jan  4 08:51:17 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  4 08:56:17 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  4 09:01:18 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan  4 09:06:18 imp-rt-01 filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known

This message is still logged every 5 minutes.

phil.davis

I checked in Diagnostics:Tables.

On a system that is running Mon Dec 31 12:20:48 EST 2012 snap (before the recent filterdns changes), my INF_iinet_ips table is long - it has the current 11 IP addresses that go with the 11 names in the table, and also has lots of old IP addresses that were dynamically allocated in the past.
(I think the recent filterdns changes will now be clearing up old entries)
On the system running Thu Jan 3 19:04:10 EST 2013 snap, there are exactly 11 IP addresses in the table, but they are out-of-date compared to the addresses I get with nslookup from my desktop. I rebooted and the 11 IP addresses are now current (so filterdns must be looking them up OK when it starts). I will monitor the table and see if the addresses go out-of-date over time.

filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known

still in syslog every 5 minutes.

eri--

Should be corrected with tomorrow snapshot.

phil.davis

2.1-BETA1 (i386)
built on Fri Jan 4 17:38:46 EST 2013
FreeBSD 8.3-RELEASE-p5
Alix 32-bit nanoBSD
filterdns starts at bootup and successfully fills gets the current IP addresses for the 11 names in my alias table.
5 minutes later it dies (when it wakes up to check again, I suppose), with this in syslog:

kernel: pid 24638 (filterdns), uid 0: exited on signal 11

ps ax | grep filterdns
reveals that there is no filterdns process any more.
I rebooted, and the same behaviour is repeatable.

cybercare

You probably need to try todays snap as he said yesterday it would be in todays and you are still listing a jan 4 snap.

dhatz

Seems that running latest snapshot filterdns still has some issues

clog system.log | tail

Jan 6 00:58:26 fw php: : Creating rrd update script
Jan 6 00:58:28 fw php: : Forcefully reloading IPsec racoon daemon
Jan 6 00:58:28 fw php: : Restarting/Starting all packages.
Jan 6 00:58:30 fw dhclient[17095]: DHCPREQUEST on em0 to x.y.z.w port 67
Jan 6 00:58:30 fw dhclient[17095]: DHCPACK from x.y.z.w
Jan 6 00:58:30 fw dhclient: RENEW
Jan 6 00:58:30 fw dhclient: Creating resolv.conf
Jan 6 00:58:30 fw dhclient[17095]: bound to x.y.z.201 – renewal in 43200 seconds.
Jan 6 00:58:31 fw php: : Resyncing OpenVPN instances for interface WAN.
Jan 6 00:58:31 fw kernel: pid 50069 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 6 00:58:32 fw php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jan 6 00:58:34 fw login: login on ttyv0 as root
Jan 6 00:58:36 fw check_reload_status: Updating all dyndns
Jan 6 00:58:36 fw check_reload_status: Restarting ipsec tunnels
Jan 6 00:58:36 fw check_reload_status: Restarting OpenVPN tunnels/interfaces
Jan 6 00:58:36 fw check_reload_status: Reloading filter
Jan 6 00:58:43 fw php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jan 6 00:58:47 fw kernel: pid 87410 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 6 01:01:22 fw php: /firewall_rules.php: Successful login for user 'admin' from: 192.168.100.12
Jan 6 01:01:22 fw php: /firewall_rules.php: Successful login for user 'admin' from: 192.168.100.12

uname -a

FreeBSD fw.localdomain 8.3-RELEASE-p5 FreeBSD 8.3-RELEASE-p5 #1: Sat Jan 5 13:23:58 EST 2013 root@snapshots-8_3-i386.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386

It had the same issue with previous snapshots:

Jan 5 00:17:03 fw kernel: pid 48375 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 5 03:25:34 fw kernel: pid 45341 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 5 03:36:13 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 03:46:55 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 03:57:37 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 04:08:19 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 04:19:01 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 04:29:44 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 04:40:26 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 04:51:08 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 5 05:02:15 fw filterdns: host_dns: failed looking up "(null)": hostname nor servname provided, or not known
Jan 6 00:58:31 fw kernel: pid 50069 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 6 00:58:47 fw kernel: pid 87410 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 6 01:08:57 fw kernel: pid 24930 (filterdns), uid 0: exited on signal 11 (core dumped)

ls -la /filterdns.core

-rw–----- 1 root wheel 4661248 Jan 6 01:08 /filterdns.core

phil.davis

2.1-BETA1 (i386)
built on Sat Jan 5 17:06:02 EST 2013
FreeBSD 8.3-RELEASE-p5
Now I should definitely have all the recent filterdns code changes. Still have the same symptoms, the table gets the correct 11 IP addresses translated from the names at boot. 5 minutes later, filterdns dies:

[2.1-BETA1][admin@imp-rt-01.imp.infn]/var/log(6): clog system.log | grep filterdns
Jan  6 11:55:27 imp-rt-01 kernel: pid 27624 (filterdns), uid 0: exited on signal 11

eri--

Hrm strange that you see that.
5 minutes is the default update interval for rechecking names.

I have run test here with 5 seconds and 10 second update intervals but no issues in that regard!
That makes still thing the snaps do not have the latest version of filterdns.

Can you make a md5 of your filterdns ?

dhatz

@ermal:

Can you make a md5 of your filterdns ?

MD5 (/usr/local/sbin/filterdns) = b25470f1942956d6f887ff87c99761c4

phil.davis

2.1-BETA1 (i386)
built on Sun Jan 6 11:15:50 EST 2013
FreeBSD 8.3-RELEASE-p5

MD5 (/usr/local/sbin/filterdns) = b25470f1942956d6f887ff87c99761c4

5 minutes after startup:

[2.1-BETA1][admin@rt-01.mydomain]/root(2): clog /var/log/system.log | grep filterdns
Jan  7 08:07:02 rt-01 kernel: pid 28781 (filterdns), uid 0: exited on signal 11

dhatz

Just bumping up this thread, since filterdns is still exiting + dumping core (note: I had just updated to latest 2.1-BETA1 snapshot)

phil.davis

Bump from me also, now on:
2.1-BETA1 (i386)
built on Sun Jan 13 19:34:21 EST 2013
FreeBSD 8.3-RELEASE-p5
and still getting:

Jan 14 12:09:19 imp-rt-01 kernel: pid 34114 (filterdns), uid 0: exited on signal 11 (core dumped)

phil.davis

Some more information. filterdns only crashes if SIGHUP is received and it goes through the "Cleaning up previous hostnames" code:

Jan 16 08:57:26 imp-rt-01 filterdns: Received signal SIGHUP(1).
Jan 16 08:57:26 imp-rt-01 filterdns: Cleaning up previous hostnames

This happens as various interfaces and OpenVPN links come up during startup - filter reloads happen a few times, and are fed to filterdns. It dies with sig 11 at the next scheduled 5 minute wakeup.
Something in the reload of filterdns.conf and attempted preservation of existing threads, removal of threads no longer needed, and addition of threads to monitor new IPs, is freeing memory that is still needed. In filterdns.c, merge_config calls clear_config:

static void
clear_config(struct thread_list *thrlist)
{
	struct thread_data *thr;

	pthread_mutex_lock(&sig_mtx);
	while ((thr = TAILQ_FIRST(thrlist)) != NULL) {
		if (debug >= 4)
			syslog(LOG_ERR, "Cleaning up hostname %s", thr->hostname);
		TAILQ_REMOVE(thrlist, thr, next);
		if (thr->thr_pid != 0)
			pthread_cancel(thr->thr_pid);
		clear_hostname_addresses(thr);
		if (thr->hostname)
			free(thr->hostname);
		if (thr->tablename)
			free(thr->tablename);
		free(thr);
	}
	pthread_rwlock_unlock(&main_lock);
}

merge_config sets thr_pid to 0 for threads that should continue on (do not need to be cancelled). But clear_config frees various data for the thread (hostname and tablename) and the thread data itself, even when the thread is not cancelled.
When the thread awakes in check_hostname at the 5 minute timer, it will have lost its thr data structure - reference to it will cause sig 11.
Perhaps it just needs this code for clear_config:

static void
clear_config(struct thread_list *thrlist)
{
	struct thread_data *thr;

	pthread_mutex_lock(&sig_mtx);
	while ((thr = TAILQ_FIRST(thrlist)) != NULL) {
		if (debug >= 4)
			syslog(LOG_ERR, "Cleaning up hostname %s", thr->hostname);
		TAILQ_REMOVE(thrlist, thr, next);
		if (thr->thr_pid != 0) {
			pthread_cancel(thr->thr_pid);
			clear_hostname_addresses(thr);
			if (thr->hostname)
				free(thr->hostname);
			if (thr->tablename)
				free(thr->tablename);
			free(thr);
		}
	}
	pthread_rwlock_unlock(&main_lock);
}

Also, "pthread_rwlock_unlock(&main_lock);" at the end seems odd. Shouldn't it be "pthread_mutex_unlock(&sig_mtx);" - to match the "pthread_mutex_lock(&sig_mtx);" at the start of the routine?
@ermal: I don't have an environment to compile in, but this might give enough clues for you to track this down.

eri--

Thanks for the analysis pushed a fix.

phil.davis

Thanks, now it doesn't crash. But somewhere in the boot process, with OpenVPN links etc coming up, it has a point where it deletes all the table entries then does not recover them again. After boot, my table that should have 11 IP addresses is empty. The log indicates entries being deleted at one point.
As a side issue:

syslog(LOG_WARNING, "\t DELETED %d addresses(%d) to table %s.", io.pfrio_nadd, address->sa_family, pfd->tablename);

should be:

syslog(LOG_WARNING, "\t DELETED %d addresses(%d) to table %s.", io.pfrio_ndel, address->sa_family, pfd->tablename);

(the debug line is reporting pfrio_nadd when it needs to report pfrio_ndel)

If I restart filterdns (kill it by hand, then use Diagnostics:Execute Command:PHP Execute to do:

mwexec("/usr/local/sbin/filterdns -p {$g['varrun_path']}/filterdns.pid -i 300 -c {$g['varetc_path']}/filterdns.conf -d 10");

It comes up nicely and puts all 11 IPs in the table.
After this, the entries survive when I stop and start an OpenVPN client process - the log looks good.
@ermal: I will PM you a log of filterdns behaviour at boot with -d 10 set.

phil.davis

Also, in filterdns.c main, it:
a) reads the config, filling in thread_list
b) loops creating a check_hostname thread for each host
c) inits main_lock
d) creates the thread for merge_config

	TAILQ_FOREACH(thr, &thread_list, next) {
		error = pthread_create(&thr->thr_pid, &attr, check_hostname, thr);
		if (error != 0) {
			if (debug >= 1)
				syslog(LOG_ERR, "Unable to create monitoring thread for host %s", thr->hostname);
		}
		pthread_set_name_np(thr->thr_pid, thr->hostname);
	}

	pthread_rwlock_init(&main_lock, NULL);
	sig_mtx = PTHREAD_MUTEX_INITIALIZER;
        sig_condvar = PTHREAD_COND_INITIALIZER;
	error = pthread_create(&sig_thr, &attr, merge_config, NULL);
	if (error != 0) {
		if (debug >= 1)
			syslog(LOG_ERR, "Unable to create signal thread %s", thr->hostname);
	}
	pthread_set_name_np(sig_thr, "signal-thread");

But check_hostname uses main_lock. So it is possible that main_lock is not initialized when check_hostname runs the first time.
Maybe that could cause some early accesses to thread_list to be inconsistent?
Maybe:

pthread_rwlock_init(&main_lock, NULL);

should be moved earlier in main.

eri--

I did make the code correct but i think the issue was mostly related to getaddrinfo code not reporting correctly the EAGAIN error.
This made entries expire, though it does not explain why it does not reenter them.

phil.davis

Upgraded to:
2.1-BETA1 (i386)
built on Fri Jan 18 03:21:43 EST 2013
It puts the 11 IP address entries in the table at the start, then sometime over the next few minutes, the addresses are all deleted from the table. The problem comes from when this message is reported 11 times (site names 1 to 11):

Jan 18 20:19:43 imp-rt-01 filterdns: Creating a new thread for host site1.dyndns-ip.com!

It already has all 11 threads for the 11 names in the table. Then, for whatever reason, it decides to create 11 new threads. In the process, it ends up clearing out the 11 table entries and never actually putting them back.
@ermal: I will send another full debug log.

dhatz

Upgraded to today's latest snapshot, I'm still getting "exited on signal 11 (core dumped)" and I see only one filterdns process running (whereas in the past there used to be more filterdns processes – for ipsec / CP / etc)

iamzam

I have been following this thread because of similar problems with filterdns crash/core dumps and I have an observation:

My problem seems to be related to the filterdns that gets started through the vpn/ipsec stuff.

After updating to the latest snapshot today:

2.1-BETA1 (amd64)
built on Fri Jan 18 04:21:30 EST 2013
FreeBSD 8.3-RELEASE-p5

I increased the filterdns debug level to 10 (in vpn.inc, line 984, '-d 10' switch) and clicked save on the VPN -> IPsec page to restart the filterdns process monitoring the vpn endpoints.

Here is the log output I get after this:

Jan 18 12:29:51 pfs check_reload_status: Syncing firewall
Jan 18 12:29:51 pfs filterdns: Found hostname vpn.net.loc with netmask 32.
Jan 18 12:29:51 pfs filterdns: found entry 10.5.0.6 for (null)
Jan 18 12:29:51 pfs filterdns: found entry 10.5.0.6 for (null)
Jan 18 12:29:51 pfs filterdns: entry 10.5.0.6 exists in table (null)
Jan 18 12:29:51 pfs filterdns: found entry 10.5.0.6 for (null)
Jan 18 12:29:51 pfs filterdns: entry 10.5.0.6 exists in table (null)
Jan 18 12:29:51 pfs filterdns: Found 1 entries for vpn.net.loc
Jan 18 12:29:51 pfs check_reload_status: Restarting ipsec tunnels
Jan 18 12:29:51 pfs filterdns: Ran command /usr/local/sbin/pfSctl -c "service reload ipsecdns" with exit status 0 because a dns change on hostname vpn.net.loc was detected.
Jan 18 12:29:53 pfs php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jan 18 12:29:58 pfs php: : Could not determine VPN endpoint for 'WAN IPv4 IPsec Mobile Phase1 '
Jan 18 12:30:03 pfs php: : Could not determine VPN endpoint for 'WAN IPv4 IPsec Mobile Phase1 '
Jan 18 12:30:03 pfs filterdns: Received signal SIGHUP(1).
Jan 18 12:30:03 pfs kernel: pid 61925 (filterdns), uid 0: exited on signal 11 (core dumped)

This is probably not causing any real problems on my system because my remote vpn endpoint dns doesn't change or if it's related to the mobile ipsec phase1 not having an endpoint I am not sure how that would affect me, but I have noticed the core dump syslog messages and I have read that there can be up to three running filterdns processes (filter, vpn, captiveportal).

Hope this helps…

eri--

I think all this happens because a filter reload will clear the contents of the table with what the filter config sends in.
I changed filterdns again to force update of addresses on table when a SIGHUP happens.

Hopefully by monday snapshot the updated filterdns will be there.

phil.davis

2.1-BETA1 (i386)
built on Sat Jan 19 20:44:40 EST 2013
Looking good - Alix nanoBSD test system has been up 9 hours. The table that should translate 11 names to 11 IPs now has 14 IP address entries. (3 of the names have dynamically switched IP in this time.) filterdns is adding to the table and not removing old entries, but I don't really care about that (feature or bug?)

bardelot

@phil.davis:

2.1-BETA1 (i386)
built on Sat Jan 19 20:44:40 EST 2013

There have been a few more changes after that date, you will have to try again tomorrow or so with a newer snapshot.

dhatz

I just upgraded to latest snapshot but still get filterdns problems:

FreeBSD fw.localdomain 8.3-RELEASE-p5 FreeBSD 8.3-RELEASE-p5 #1: Sat Jan 19 21:12:44 EST 2013 root@snapshots-8_3-i386.builders.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386

MD5 (/usr/local/sbin/filterdns) = 6949816348947b7762586fe3c59b356e

…
Jan 21 00:05:28 fw kernel: pid 47308 (filterdns), uid 0: exited on signal 11 (core dumped)
Jan 21 00:05:29 fw check_reload_status: Restarting ipsec tunnels
Jan 21 00:05:30 fw login: login on ttyv0 as root
Jan 21 00:05:36 fw php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jan 21 00:05:37 fw check_reload_status: Updating all dyndns
Jan 21 00:05:37 fw check_reload_status: Restarting OpenVPN tunnels/interfaces
Jan 21 00:05:38 fw check_reload_status: Reloading filter
Jan 21 00:05:40 fw kernel: pid 83611 (filterdns), uid 0: exited on signal 11 (core dumped)

eri--

dhatz that happens probably because of upgrade is not replacing the filterdns process.
Can you kill all you filterdns processes before running an upgrade and try again or
extract the archive of the upgrade and install manually the filterdns binary, it is located on usr/local/sbin iirc.

I am tracking even this issue of upgrade not replacing binaries at some time.

dhatz

Indeed it seems that the filterdns binary is not replaced by the upgrade process.

I will upgrade as soon as a new 2.1 snapshot image becomes available (currently the latest snapshot is from 19-Jan) and let you know how it goes.

phil.davis

nanobsd upgrade to 2.1-BETA1 (i386) built on Tue Jan 22 05:52:55 EST 2013 gets the version feature (1.1), but that is kind of obvious since nanoBSD is provided with a full slice. We will see what dhatz gets with a upgrade of a full install.
filterdns working well for me - but it does accumulate all the IP addresses known to it over time for the list of names. My table now has 15 IPs for 11 names.

dhatz

@ermal:

dhatz that happens probably because of upgrade is not replacing the filterdns process.
Can you kill all you filterdns processes before running an upgrade and try again or
I am tracking even this issue of upgrade not replacing binaries at some time.

Just a quick reminder that doing an upgrade still won't replace the old filterdns binary.

Btw I have tried killing all filterdns processes before running an upgrade (and verified they had been killed just before starting the upgrade procedure).

eri--

Is the issue fixed for you dhatz?

dhatz

Ermal, I upgraded the filterdns binary to
MD5 (/usr/local/sbin/filterdns) = af355106eef6aff00d9e6653cca696eb

However it seems that the new filterdns needs too much memory at system startup, causing errors like:

swap_pager_getswapspace(16): failed
swap_pager_getswapspace(12): failed
swap_pager_getswapspace(6): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(12): failed
swap_pager_getswapspace(9): failed

and it dies shortly after…

I've been running the latest pfsense-2.1 snap in a 256MB VM for the past ~10 months and never had this type of problem before.

eri--

Do you have a long list of aliases in the one where you have the hostname?

AhnHEL

@dhatz:

However it seems that the new filterdns needs too much memory at system startup, causing errors like:

swap_pager_getswapspace(16): failed
swap_pager_getswapspace(12): failed
swap_pager_getswapspace(6): failed
swap_pager_getswapspace(16): failed
swap_pager_getswapspace(12): failed
swap_pager_getswapspace(9): failed

and it dies shortly after…

I'm seeing this too on my Atom box but not on my Whitebox. Same snap from yesterday and both amd64. Filterdns eats up all my memory and then uses up all the swap space before it dies.

dhatz

@ermal:

Do you have a long list of aliases in the one where you have the hostname?

I have

two (2) aliases in fw -> aliases
www_google_com
www_paypal_com
(note: this was just for testing)
one (1) hostname in IPsec
no "allowed hostnames" in CP

In the past (until ~2 months ago) these settings resulted into two filterdns processes: one for fw-aliases and one for ipsec, none for CP.

jimp

It's chewing through 100% cpu and all my RAM until it runs out of swap space for me, and I only have three aliases that contain hostnames.

truss -p on the filterdns proc shows it trying doing mmap over and over again.


mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1953497088 (0x8b900000)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1952448512 (0x8ba00000)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1951399936 (0x8bb00000)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1950351360 (0x8bc00000)
mmap(0x0,1048576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = -1949302784 (0x8bd00000)

I have a few decent-sized aliases but nothing huge. The filterdns.conf file on this box was only three lines. The size of the aliases involved in the filterdns thread were 1, 63, and 3. So it shouldn't have been all that busy/large.

68313 root     124   20   545M   543M RUN      0:05 35.35% filterdns{github.com}
68313 root     124   20   545M   543M RUN      0:05 35.35% filterdns{filterdns}
68313 root     124   20   545M   543M RUN      0:05 35.25% filterdns{some.other.hostname.you.dont.need.to.see}
  262 root      76   20  3416K   736K kqread   1:14 12.35% check_reload_status
68313 root      76   20   545M   543M ucond    0:00 10.99% filterdns{signal-thread}

filterdns -v shows 1.1.

Size and sha256 match the one on the builder so it is the most current build. (tar is set to preserve old creation times, so of course the date doesn't update…)

-r-xr-xr-x  1 root  wheel  24160 Nov 19 05:07 /usr/local/sbin/filterdns
SHA256 (/usr/local/sbin/filterdns) = 193ebd8250147041b79385d84efe0f5d09f9ce868ba666b18f91b5098ecce1f3

It was being run with the following parameters:

/usr/local/sbin/filterdns -p /var/run/filterdns.pid -i 300 -c /var/etc/filterdns.conf -d 1

phil.davis

@ermal - when you sort this out, and each time filterdns is updated, can you bump the version number in filterdns.c - that will make it very easy for us all to quickly see which version we have.

So many filterdns instances…

clog system.log | tail

uname -a

ls -la /filterdns.core

Products

Services

Support

News

Resources

Company

Our Mission

Subscribe to our Newsletter