A few times, I've found new connections to nntpcached just disconnecting.
Today I was able to run strace against it, and see what was happening.
The master nntpcached accepts the new incoming connection, and forks to
deal with it. The child then ends up closing the socket with the new
connection on it, amongst the server sockets. This means that it fails
to set up the communication.
Here is the relevant section of the strace from the forked child:
close(8) = 0
close(9) = 0
close(7) = 0
munmap(0x40008000, 4096) = 0
sigaction(SIGCHLD, {SIG_DFL}, {0x8003330, [],
SA_INTERRUPT|SA_NOMASK|SA_ONESHOT}) = 0
sigaction(SIGHUP, {SIG_DFL}, {0x8003250, [],
SA_INTERRUPT|SA_NOMASK|SA_ONESHOT}) = 0
sigaction(SIGPIPE, {0x80033e0, [],
SA_INTERRUPT|SA_NOMASK|SA_ONESHOT}, {SIG_IGN}) = 0
close(3) = 0
close(0) = 0
close(1) = 0
close(2) = 0
close(10) = 0
close(11) = 0
close(12) = 0
* close(13) = 0
setsockopt(13, SOL_SOCKET, SO_SNDBUF, [8192], 4) = -1 EBADF
The line marked '*' is the one where the accepted socket from the client
is closed.
Looking at the code, it would appear that somehow scfg->fd is still set
to a fd that is no longer in use.
I've had a scan for a place where this could happen, but there is nothing
obvious. It always seems that when scfg->fd is closed, it is set to -1.
One factor that may be important is that one of the configured servers
was being reluctant ("5xx Bog Off", or similar).
I'm just hoping that the above description will help someone track down
the actual cause.
--
`O O' | Nick.Holloway@alfie.demon.co.uk http://www.alfie.demon.co.uk/
// ^ \\ | Nick.Holloway@parallax.co.uk http://www.parallax.co.uk/~alfie/
