Hi..
I'm testing nsd for use with around 55000 zones (primary named servers).
i was making the big initial amout of zonetransfers, when my axfr master
reloaded...
now i have a nsd-xfer hanging around.. and nsdc update will never stop..
lappy# ps auxwww | grep nsd
djam 45775 82.9 0.1 2468 1420 p7 R+ 1:07PM
27:38.97 /usr/local/sbin/nsd-xfer -z daxxx.dk -f /etc/nsd/gdns/daxxx.dk.axfr
-s 0 194.192.xx.xxx
x's to protect the innocent's 
it's like nsd-xfer is not able to detect the broken transfer and exit? it just
hangs around..
FreeBSD: 5.3
NSD 2.2.0 (not from ports)
regards, Peter
a message of 26 lines which said:
it's like nsd-xfer is not able to detect the broken transfer and
exit? it just hangs around..
May be the patch in http://www.nlnetlabs.nl/bugs/show_bug.cgi?id=94
will help you? Warning: I have not tested it on a production machine.
May be the patch in http://www.nlnetlabs.nl/bugs/show_bug.cgi?id=94
will help you? Warning: I have not tested it on a production machine.
It may work and it looks like something which might be useful anyway,
but it doesn't look like it's getting to the root of this particular
problem. nsd-xfer appears to be spinning somewhere and chewing up CPU,
which is bad stuff. This shouldn't happen in the first place.
It might be helpful if Peter compiled a version of nsd-xfer with
debugging symbols enabled and then attached gdb to the process to see
where it's looping. A backtrace would be good.
Nick
a message of 14 lines which said:
nsd-xfer appears to be spinning somewhere and chewing up CPU, which
is bad stuff.
It *seems* (warning: this thinking comes only from a static
observation of the code) that read_socket() loops forever when read(2)
returns zero (for instance if the TCP conenction was shut down).
If so, my patch address this issue.
As you said, gdb will prove or disprove my theory. strace or truss or
a similar tool may also show calls to read(2) which returns zero.
gdb /usr/local/sbin/nsd-xfer
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
(gdb) attach 72746
Attaching to program: /usr/local/sbin/nsd-xfer, process 72746
Reading symbols from /usr/lib/libwrap.so.3...done.
Loaded symbols for /usr/lib/libwrap.so.3
Reading symbols from /lib/libcrypto.so.3...done.
Loaded symbols for /lib/libcrypto.so.3
Reading symbols from /lib/libc.so.5...done.
Loaded symbols for /lib/libc.so.5
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
0x281d1557 in read () from /lib/libc.so.5
(gdb) bt
#0 0x281d1557 in read () from /lib/libc.so.5
#1 0x0804b63e in read_socket (s=3, buf=0xbfbf28b2, size=2) at nsd-xfer.c:300
#2 0x0804b735 in receive_response (state=0xbfbf4884) at nsd-xfer.c:493
#3 0x0804c259 in main (argc=252, argv=0xbfbfea60) at nsd-xfer.c:695
(gdb) Quit
a message of 47 lines which said:
(gdb) bt
#0 0x281d1557 in read () from /lib/libc.so.5
#1 0x0804b63e in read_socket (s=3, buf=0xbfbf28b2, size=2) at nsd-xfer.c:300
#2 0x0804b735 in receive_response (state=0xbfbf4884) at nsd-xfer.c:493
#3 0x0804c259 in main (argc=252, argv=0xbfbfea60) at nsd-xfer.c:695
This is what I expected and, indeed, I believe my patch fixes
this. (You can use truss, too, since it displays the return code of
read, it will be one more proof.)
[Quoting Stephane Bortzmeyer, on Feb 3, 22:41, in "Re: minor bug in nsd ..."]
a message of 26 lines which said:
> it's like nsd-xfer is not able to detect the broken transfer and
> exit? it just hangs around..
May be the patch in http://www.nlnetlabs.nl/bugs/show_bug.cgi?id=94
will help you? Warning: I have not tested it on a production machine.
I've looked at the patch and it seems to me that it addresses the
problem properly. Thanks Stephane!
Erik, the current maintainer of NSD, is moving into a new house and
is off-line for a long weekend. Before we can provide a new release
with this patch, rigid testing of the patch on the various platforms
is required. So, this may take a few more days. In the meantime,
Peter might try whether Stephane's patch works for him (and please
report)?
Regards,
-- ted
Erik, the current maintainer of NSD, is moving into a new house and
is off-line for a long weekend.
uhh 
OFFline? that gotta hurt..
Before we can provide a new release
with this patch, rigid testing of the patch on the various platforms
is required. So, this may take a few more days. In the meantime,
Peter might try whether Stephane's patch works for him (and please
report)?
It seems to do the trick.
regards, Peter
no.. but i'm moving to copenhagen the 26 febuary
so, i'll learn i guess
Regards, Peter