Ok, the parsing error is solved in snapshot 676. But pdns still failed
on startup.
First test:
Mar 08 09:54:03 [bindbackend] error at Thu Mar 8 09:54:03 2007 parsing
'166.255.217.in-addr.arpa' from file
'/var/named/master/asp/P217.255.166': St9bad_alloc
Mar 08 09:54:03 [bindbackend] parsing '167.255.217.in-addr.arpa' from
file '/var/named/master/asp/P217.255.167'
Mar 08 09:54:13 About to create 3 backend threads for UDP
Mar 08 09:54:13 Not authoritative for 'pd9ffc161.dip0.t-ipconnect.de',
sending servfail to 87.126.122.171
Mar 08 09:54:13 Not authoritative for 'p54884082.dip0.t-ipconnect.de',
sending servfail to 217.41.21.58
Mar 08 09:54:13 Not authoritative for 'p54822a4a.dip0.t-ipconnect.de',
sending servfail to 195.39.121.49
Mar 08 09:54:13 Not authoritative for 'p50893713.dip0.t-ipconnect.de',
sending servfail to 203.187.202.5
Mar 08 09:54:13 Not authoritative for 'p54a7097a.dip0.t-ipconnect.de',
sending servfail to 82.119.151.162
Mar 08 09:54:13 Not authoritative for 'p57b1c902.dip0.t-ipconnect.de',
sending servfail to 122.163.109.211
Mar 08 09:54:14 Done launching threads, ready to distribute questions
Mar 08 09:54:17 Not authoritative for 'p548b56c2.dip.t-dialin.net',
sending servfail to 88.233.7.38
Mar 08 09:54:19 Distributor misses a thread (1<3), spawning new one
Mar 08 09:54:19 5050 questions waiting for database attention. Limit is
5000, respawning
Mar 08 09:54:30 Caught an exception instantiating a backend, cleaning up
Mar 08 09:54:30 Communicator thread died because of STL error: St9bad_alloc
and the second:
Mar 08 10:09:05 About to create 3 backend threads for UDP
Mar 08 10:09:05 Caught an exception instantiating a backend, cleaning up
Mar 08 10:09:20 Not authoritative for 'p54884082.dip0.t-ipconnect.de',
sending servfail to 217.41.21.58
Mar 08 10:09:20 Not authoritative for 'p54a7097a.dip0.t-ipconnect.de',
sending servfail to 82.119.151.162
Mar 08 10:09:20 Done launching threads, ready to distribute questions
Mar 08 10:09:20 Not authoritative for 'pd9ffc161.dip0.t-ipconnect.de',
sending servfail to 87.126.122.171
Mar 08 10:09:20 Not authoritative for 'p57b1c902.dip0.t-ipconnect.de',
sending servfail to 122.163.109.211
Mar 08 10:09:20 Not authoritative for 'pd9ffc161.dip0.t-ipconnect.de',
sending servfail to 87.126.122.171
Mar 08 10:09:20 Not authoritative for 'p54884082.dip0.t-ipconnect.de',
sending servfail to 217.41.21.58
Mar 08 10:09:20 Not authoritative for 'p54a7097a.dip0.t-ipconnect.de',
sending servfail to 82.119.151.162
Mar 08 10:09:20 Not authoritative for 'p54884082.dip0.t-ipconnect.de',
sending servfail to 217.41.21.58
Mar 08 10:09:20 Not authoritative for 'pd9ffc161.dip0.t-ipconnect.de',
sending servfail to 87.126.122.171
Mar 08 10:09:20 Communicator thread died because of STL error: St9bad_alloc
Mar 08 10:09:20 Not authoritative for 'p57b1c902.dip0.t-ipconnect.de',
sending servfail to 122.163.109.211
Mar 08 10:09:20 Distributor misses a thread (4<3), spawning new one
terminate called after throwing an instance of 'Mar 08 10:09:20 TCP
Connection Thread died because of STL error: St9bad_alloc
std::bad_alloc'
what(): St9bad_alloc
Mar 08 10:09:20 Got a signal 6, attempting to print trace:
Mar 08 10:09:20 pdns_server [0x80bd0d7]
Seems to me that it try to allocate memory and then fail.
Regards,
Thomas
bert hubert wrote:
On Wed, Mar 07, 2007 at 10:12:22AM +0100, trietz wrote:
Mar 07 09:59:43 No master domains need notifications
Exiting because of STL error: Can't parse zone line '$include
master/SOA.asp'
This is fixed in snapshot 967, thanks for the report!
See http://svn.powerdns.com/snapshots/967
Snapshot 966 fixed that this error is not fatal, 967 fixes the error itself.
This problem was caused by our move to the new zone parser for the auth
server as found in the recursor.
Kind regards,
bert hubert
Mar 07 09:59:43 Exiting because of STL error: Can't parse zone line
'$include master/SOA.asp'
Other ideas?
I will take a look at the pipe backend. Thanks for the information.
Thomas
bert hubert wrote:
On Tue, Mar 06, 2007 at 04:36:05PM +0100, trietz wrote:
When i start pdns in the monitor mode i can see it start to parse the
zone files succesfully. The memory usage of pdns grows and when
the system memory reach more than 4.5 gb the pdns process get killed
with the following message:
This looks like an unrelated bug. I'd normally tell you to try using the
snapshot, but earlier today it was reported that the binaries on
http://svn.powerdns.com/snapshots/959/ crashed on startup.
It may work for you however.
For such vast volumes of reverse zones, a specialised pipe backend might
make sense, as you are now storing heaps and heaps and heaps of
'1.2.3.4.in-addr.arpa' strings which use up a lot of memory.
Bert
!DSPAM:45ee8205273628139311174!
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
