[Pdns-users] 3.4.8 -> 4.0.1: Exiting because communicator thread died with STL error: stou

[Oliver Peter]

Hi,

During the update process from our 3.4.8 servers to 4.0.1 we encountered
a dying/looping pdns instance.  3.4.x has been stable for the last
~6months.
We already moved 4 of our 5 auth NS to 4.0.1, all of them are running
FreeBSD10, all of them are working fine as expected.

Today we upgraded our last instance and this one showed us a strange
error (Murphy's law) so we had to downgrade to 3.4.8.  The service comes
up OK, servers a couple of requests, dies, and comes up again, etc:

	Sep 15 06:45:07 a pdns[14120]: PowerDNS Authoritative Server 4.0.1 (C) 2001-2016 PowerDNS.COM BV
	Sep 15 06:45:07 a pdns[14120]: Using 64-bits mode. Built using clang 3.4.1 (tags/RELEASE_34/dot1-final 208032) on Sep 15 2016 08:35:02 by root at localhost
	Sep 15 06:45:07 a pdns[14120]: PowerDNS comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it according to the terms of the GPL version 2.
	Sep 15 06:45:07 a pdns[14120]: Creating backend connection for TCP
	Sep 15 06:45:07 a pdns[14120]: Master/slave communicator launching
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	Sep 15 06:45:07 a pdns[14120]: About to create 8 backend threads for UDP
	[...]
	Sep 15 06:45:09 a pdns[14120]: Exiting because communicator thread died with STL error: stou
	Sep 15 06:45:09 a kernel: pid 14120 (pdns_server), uid 1001: exited on signal 8
	Sep 15 06:45:09 a pdns[93674]: Our pdns instance (14120) exited after signal 8
	Sep 15 06:45:09 a pdns[93674]: Respawning

Here comes the pdns.conf:

	setuid=pdns
	setgid=pdns

	do-ipv6-additional-processing=yes
	out-of-zone-additional-processing=no

	security-poll-suffix=

	allow-axfr-ips=<some ranges>
	disable-axfr=no
	version-string=anonymous
	allow-recursion=127.0.0.1/32
	cache-ttl=250
	daemon=yes

	max-ent-entries=1500000
	default-soa-name=hostmaster.XXX

	distributor-threads=8
	receiver-threads=6
	max-queue-length=500000
	overload-queue-length=0
	negquery-cache-ttl=5
	any-to-tcp=yes
	queue-limit=20000

	guardian=yes
	max-tcp-connections=900
	query-cache-ttl=20 #default

	slave=no
	master=yes

	slave-cycle-interval=600
	soa-minimum-ttl=86400

	query-local-address=<local IP>

	gmysql-socket=/tmp/mysql.sock
	gmysql-user=powerdns
	gmysql-password=XXXXXXXXXXXXXXX

	launch=gmysql

	local-address=<about 150 addresses in here>
	local-ipv6=<about 150 addresses in here>

Basically the machines are running almost the same config (except IP
settings of course) and serving almost the same zone database (~2mio
domains, ~20mio records).

On the same machine we have another pdns instance running, same
binaries, a bit less zones/records, different config profile - this one
was pretty stable.

Any hints appreciated.


-- 
Oliver PETER       oliver at gfuzz.de       0x456D688F