On 2007, Jul 6, at 02:09, Angel L. Mateo wrote:
This is the logs registered with an increased log level: Jul 6 09:01:21 canis4 slapd[10389]: daemon: read activity on 14 Jul 6 09:01:21 canis4 slapd[10389]: daemon: read activity on 31 Jul 6 09:01:21 canis4 slapd[10389]: daemon: read activity on 44 Jul 6 09:01:21 canis4 slapd[10389]: connection_read(44): input error=-2 id=84, closing. Jul 6 09:01:21 canis4 slapd[10389]: daemon: removing 44 Jul 6 09:01:21 canis4 slapd[10389]: conn=84 fd=44 closed (connection lost)
Can you turn on some more verbose logging on the client-side to see if it thinks there was a bad response, or it's sent a query that is unanswered, etc?
If not, it sounds like it's time to get even more basic and look lower down in the stack. Here's some of the network-level debugging it sounds like you might have to start doing:
You should also have a connection log line like:
Jul 6 09:01:00 canis4 slapd[10389]: conn=84 fd=44 ACCEPT from IP= $client_ip:$port (IP=0.0.0.0:389)
Start up a tcpdump on both the client and the server and watch for the problem to recur. Compare the tcpdump output files looking for the newly logged source $port to see that either the client and the server are not seeing the same packets or that the client is doing something strange (like actually not sending output or closing the connection).
Your original message also mentioned some other changes:
We have a clustered openldap server (slapd version 2.2.23 [...snip...]
But now we are renovating our servers and we want to upgrade them to a new one based on openldap 2.3.30 (in two debian etch servers), but we are having problems.
I'm not sure what your "clustered" architecture is, are you using a load-balancing or other layer-3 directing front-end? If so, is that exactly the same front-end on both the production and test set-ups? Regardless, you would need to add those tcpdumps to both sides of the load-directing box as well to make sure it's not behaving differently in some way.
-philip