NT4: 8.3.3: Errcode: 10038: Socket operation on non-socket

Danny Mayer mayer at gis.net
Tue Oct 1 01:16:41 UTC 2002


At 10:05 AM 9/30/02, Randy wrote:

>I have a master (nt4, sp 6a, bind 8.3.3, ~58,000 master zones) and 4 slaves
>(nt4, sp 6a, bind 8.3.3, ~58,000 slave zones) in a test environment before
>deploying.
>
>After ~ 12-24 hours the slaves *randomly* crash with 2 errors in the 
>application
>log - (both the same):
>
>accept: Errcode: 10038: Socket operation on non-socket
>accept: Errcode: 10038: Socket operation on non-socket
>(There are no other significant messages in the log.)

This is a known problem and appears to happen for no obvious reason.

>All zones have previously transferred to the slaves, and the entire system
>is completely unloaded (no client activity whatsoever), other than the serial
>number checks by the slaves against the master.
>
>Although it may be a coincidence, the master has never crashed, suggesting
>the issue may involve the slave side of serial number checks/zone transfers
>- as there is absolutely no other activity on the system.

While it's possible on the slave, I would expect an accept problem on the
master since zone transfers are done through TCP. If the slave is crashing
on an accept error then there must have been some sort of TCP request
that was being accepted. If you're running query logging do you see any
requests coming in for something that would require a large data packet
in the response?

>(I searched and saw other people were having similar issues, but I could
>not locate a fix.  I was unable to use BIND Version 9.2.2rc1 as I 
>*immediately*
>got the same error.)

One of the things that I have noticed is that the socket number is
occasionally a very large number for no obvious reason and even
though it's supposed to be an unsigned 32-bit integer most values
I've seen fall into the 500-2000 range.

This should be fixed in 9.3.0 since the code is totally different and doesn't
have the limitations of either BIND 8 or BIND 9.2.x.

>Thank you in advance,
>
>Randy Williams

Danny



More information about the bind-users mailing list