Sockets leaking?

[Stephen B. <st...@br...>]

Hi,

I am using the perl-back backend to OpenLDAP's slapd, and using perl-ldap to 
forward some requests on to another LDAP server.

I need to be able to cope with non-local servers going on- and off-line, 
while keeping a persistant connection where possible.

As far as I can see, there seems to be no way to totally tear down one of my 
LDAP connections, if the foreign server stops responding.

Here's the order of operations:

- foreign server stops responding
- perl-ldap attempts a "search" on $ldap, which was previously a valid 
connection
- search fails with code 1, "I/O Error Connection reset by peer"
- I attempt to do an unbind(), which appears to succeed (no error message)
- lsof shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE"
- I make a new connection to the server, which succeeds this time
- lsof STILL shows the socket as "no PCB, CANTSENDMORE, CANTRCVMORE", though 
there's now a new socket as well
- these unallocated sockets continue to stack up till the process is out of 
fd's

So, why aren't the sockets being closed? Is this supposed to happen via 
garbage collection? If so, the process of creating a new perl-ldap instance 
in $ldap seems not to be triggering GC in my case...

As far as I can see I am not creating any other references to $ldap itself, 
though I am caching arrays of strings returned from the search results - but 
I don't imagine this creates references to $ldap.

To fix this for the time being, after getting the Connection Reset error I 
(i) call $ldap->unbind, and (ii) close $ldap->socket()

This seems to stop the file descriptor problem, but I am concerned that there 
may be a larger scale memory leak going on.

- Can anyone shed any light on this?
- Should there be some other method in perl-ldap that does a more thorough, 
explicit cleanup?

Many thanks,
Stephen Brandon
st...@br...