[Twisted-Python] CLOSE_WAIT (debian)

[Josef Novak]

Hi,
  I have a fairly simple twisted daemon based on the starpy protocol,
which I am running in combination with the asterisk pbx.  I sometimes
this daemon accumulates CLOSE_WAIT connections in a rather
unpredictable fashion, which when stacked up eventually cause the
daemon to stop responding to new connections.

My understanding is that there is no default timeout for the
CLOSE_WAIT socket state, as per the relevant rfc standard, and that in
any netstat declares that CLOSE_WAIT indicates that the remote end of
the connection has shut down, and that it is now up to the local
application to finish closing the socket.

The implication is that there is something wrong with my application
code, however before posting the whole thing I'd like to know if there
are any cannonical reasons for this kind of issue being raised in
twisted applications.  For instance is this likely to occur when one
uses defertothread for blocking third party code, and the child
process spawned to handle this returns to find the parent process
already gone? ( e.g. my twisted app spawns for a new call from
asterisk, but the call instance is destroyed for some reason before
the defertothread that it executes returns?)

I'm having trouble reliably causing the issue, but it continues to pop
up, so any general information about regarding debugging twisted
applications would be of help.

Thanks!