Date: Sun, 31 Dec 2006 20:03:54 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Doug Barton <dougb@freebsd.org> Cc: FreeBSD mailing list <freebsd-stable@freebsd.org> Subject: Re: BIND-9.3.2 (from 5.5-STABLE) segfault under load... Message-ID: <Pine.BSF.3.96.1061231180210.6440A-100000@gaia.nimnet.asn.au> In-Reply-To: <4596D4B5.5080004@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1061231180210.6440A-100000>