zone transfer exits

[Jim Reid]

>>>>> "Arjen" == A van Drie <av3 at xs4all.nl> writes:

    Arjen> same os, less stripped, no firewalling, single ip, running:
    Arjen> sendmail, httpd and bind. Also chrooted, containg five
    Arjen> primary zonefiles, and three secondary for subdomains
    Arjen> running primary on ns2. And on this machine those three
    Arjen> zonetransfers exit with a code 13

    Arjen> and in the 'secondary' dir it writes a file called

    Arjen> subdomain.9HB45b

    Arjen> or another seemingly random 6 char string after
    Arjen> 'subdomain.' being 0 bytes of size.

It would have helped if you'd shown (a) the relevant zone{} statements
from named.conf; (b) the actual names of the files created in the
"'secondary' dir" - whatever that is; (c) the domain names in
question. Hiding these things makes it difficult for someone else to
work out what's in your config files and try to assess what's wrong.
Even if the stuff is behind a firewall, it's a lot easier to discuss
and explain problems by using the actual domain names instead of
vague and confusing references to things like "thissubdomain" or
"thatsubdomain".

    Arjen> As user 'bind' (of course the user under which bind runs) i
    Arjen> issue the command:

    Arjen> ./usr/sbin/named-xfer -d 2 -l /tmp/xfer.loggie \
    Arjen>     -z subdomain -f zone/secondary/subdomain ns2

    Arjen> works fine.

    Arjen> Can anyone already point me in the right direction?

If the zone transfers work fine when you run them by hand, then the
problem has to be in your name server setup. [If they had failed then,
there would be a connectivity or access problem to the master server
or else the master server wasn't authoritative for the domain(s).]
When you run named-xfer by hand, are you doing it in *exactly* the
same chroot'ed environment with the same UID/GID as named would be
using?

Is the version of named-xfer the one that came with the version of
named that you're running? ie It's named-xfer for 8.2.2P5 that's used
with named 8.2.2P5 and not one from some other version of bind? Are
there any differences between the other named.conf that works for one
chroot'ed environment and the one that doesn't? Maybe there's a a
wrong pathname or missing directory somewhere on the failing system?
Or perhaps the file or directory access permissions and ownerships are
not correct. Could some critical system file - a shared library? - be
missing from the name server's chroot'ed environment?

The files called things like "subdomain.9HB45b" are probably the temp
files that named-xfer creates to store the incoming data during the
zone transfer. It looks like named-xfer might be dying as soon as
these are created. Do their modification dates tally with named trying
the zone transfers, or are they just stale junk that's been left lying
around?

What do the logs on the master and slave servers have to say about the
zone transfers? What's in the logs after the NOTIFY reports you
posted? Do connections get established for the zone transfers? [Have
you tried turning up the debugging on the slave server?] Look for
syslog messages from named-xfer wherever your system sticks LOG_DAEMON
reports.

FWIW, signal 13 is SIGPIPE. It's usually generated when one end of a
pipe (or TCP connection) goes away unexpectedly.

PS: There's no need to post answers to these questions here. They're
just pointers to things you can check. If you're still stuck for a
solution after checking them, by all means post again. But next time,
please be sure to provide all the relevant information.