BIND-9.3.2 (from 5.5-STABLE) segfault under load...

Ian Smith smithi at
Sun Dec 31 01:16:31 PST 2006

On Sat, 30 Dec 2006, Doug Barton wrote:

 > Chuck Swiger wrote:
 > > Hi--
 > > 
 > > I had named segfault a day or so ago under high load ("adnslogres -c
 > > 200" against a webserver logfile) after logging the following:
 > Hard to tell if your problem here is related to running on 5.5 or not,
 > but of course recommendation number one is to consider upgrading to
 > 6.x. Recommendation number two is to upgrade BIND to 9.3.3, preferably
 > by upgrading to 6.2-RC2, or by upgrading to the head of RELENG_5, or
 > as a last resort by using the port, with or without the option to
 > replace the base BIND.

Similarly to Chuck (but on a much smaller scale :) with 'BIND 9.3.2-P2
-u bind -t /var/named' on 5.5-STABLE #0: Sun Nov 19 20:22:12 EST 2006

No real issues apart from inability to get trace and/or querylog working
yet, but I'll leave that until after upgrading as advised first ..

But .. cut to

 > > Named is being invoked via "-4 -u bind -c named.conf -t /var/named"; but
 > > it could not dump core as /var/named is owned by root. 
 > Check out the dump-file directive in the ARM. I have a directory in
 > the chroot called /var/dump, owned by the bind user, and the following
 > in my named.conf:
 > options {
 > 	...
 > 	dump-file "/var/dump/named_dump.db";
 > 	...
 > };

Standard issue unless Chuck disabled it.  'rndc dumpdb' dumps cache and
zones to (seen from outside) /var/named/var/dump/named_dump.db fine. 

But how would you tell named to drop its core there?

 > > I've changed
 > > that temporarily so I ought to be able to get a corefile if I can
 > > reproduce it.

Would letting bind own the chroot dir adversely affect the security of
the sandbox re breaking chroot?  (temporarily)

It looks like you'd have to hack /etc/rc.d/named to stop it mtree'ing
'.' ownership back to root anyway?

 > See above.
 > > As the subject mentions, this is a Dell 1850 (rackmount PowerEdge)
 > > running FreeBSD-5.5 & BIND-9.3.2; until just now, everything had been
 > > running stably for months at a time.
 > I assume you've checked the usual suspects, dead fans, other hardware
 > problems, etc?
 > hth,
 > Doug

Cheers, Ian

More information about the freebsd-stable mailing list