Skip Menu |
 

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 55414
Status: rejected
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: felix.ostmann [...] thewar.de
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.66
Fixed in: (no value)



Subject: simple server hangs in close_wait
Download (untitled) / with headers
text/plain 1.7k
After some/many requests N::D::N hangs with CLOSE_WAIT. # netstat -pan | grep CLOSE tcp 1 0 x.x.x.x:53 y.y.y.y:50055 CLOSE_WAIT 31947/perl # strace -p 31947 Process 31947 attached - interrupt to quit accept(7, # host test.tld x.x.x.x ;; connection timed out; no servers could be reached # host test.tld z.z.z.z ;; connection timed out; no servers could be reached # script sub reply_handler { my($qname,$qclass,$qtype,$qhost,$qpacket) = @_; my($rcode,@ans,@auth,@add,%args); # simple if ... push(@ans, Net::DNS::RR->new(sprintf('%s %s %s',$qname, 'A', 'w.w.w.w'))), # no blocking or anything else. Code not waithing here (checked with debugprints). $rcode ||= 'NOERROR'; return ($rcode,\@ans,\@auth,\@add,\%args); } while( 1 ) { eval { my $ns = Net::DNS::Nameserver->new( 'LocalAddr'=>['z.z.z.z','x.x.x.x'], 'ReplyHandler'=>\&reply_handler, 'Verbose'=>1, ) or die('Can\'t create nameserver object.',$!); $ns->main_loop(); }; $@ && warn($@) && sleep(30); } # Verboselog Waiting for connections... TCP connection from y.y.y.y:35812 TCP connection from y.y.y.y:50055 Received 38 octets from tcp:y.y.y.y:35812 Removed 2 octets from the input buffer from tcp:y.y.y.y:35812. tcp:y.y.y.y:35812 said his query contains 36 octets. query 23767: (test.tld, IN, NS) - Queued 87 octets to tcp:y.y.y.y:35812 Received 38 octets from tcp:y.y.y.y:50055 Removed 2 octets from the input buffer from tcp:y.y.y.y:50055. tcp:y.y.y.y:50055 said his query contains 36 octets. query 1186: (test.tld, IN, NS) - Queued 87 octets to tcp:y.y.y.y:50055 Sent 87 of 87 octets to tcp:y.y.y.y:35812. Sent 87 of 87 octets to tcp:y.y.y.y:50055. Received octets from tcp:y.y.y.y:35812 Connection to tcp:y.y.y.y:35812 closed or lost. nothing more :(
From: felix.ostmann [...] thewar.de
Download (untitled) / with headers
text/plain 128b
Only occure when used more listening ips. i copied the script and run now two deamons, each with only 1 ip ... no more problems!
Download (untitled) / with headers
text/plain 342b
Hi Felix, I have not yet been able to reproduce your error. What version of Net::DNS are you using? And how come your servers only listen to TCP? Regards, Willem On Tue Mar 16 07:22:34 2010, Sadrak wrote: Show quoted text
> Only occure when used more listening ips. i copied the script and run > now two deamons, each with only 1 ip ... no more problems!
From: felix.ostmann [...] thewar.de
Download (untitled) / with headers
text/plain 799b
The server is now offline for ever, so all i have is here in the report and my brain. Version? Was submitted in the bugreport (0.66) I used that for some .de-domains and the nic make some DNS checks with TCP. Perhaps they do the tests parallel and the server got a deadlock? Only thing i now: running two daemons with each 1 IP fixed that. running one daemon with 2 IPs was broaken. Am Mo 10. Jan 2011, 10:39:03, WILLEM schrieb: Show quoted text
> Hi Felix, > > I have not yet been able to reproduce your error. What version of > Net::DNS are you using? And how come your servers only listen to TCP? > > Regards, Willem > > On Tue Mar 16 07:22:34 2010, Sadrak wrote:
> > Only occure when used more listening ips. i copied the script and run > > now two deamons, each with only 1 ip ... no more problems!
>
Download (untitled) / with headers
text/plain 579b
Sorry Felix, I am still unable to reproduce your error. I've tried sending parallel queries to nameservers listening on multiple IP-adresses, but everything keeps working fine here. The handling of events is done asynchronously with select. It should not matter if a nameserver listens on one or more addresses. I believe there might have been a system specific issue which caused the problem. I am closing the ticket for now (with status rejected). It would be nice to know if more people suffer from this problem before starting to work on it again. Okay? Regards, Willem
From: felix.ostmann [...] thewar.de
OK, sorry for that bad bugreport :-/


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.