After 7 days of operation suddenly ldap does not respond any more and keeps printing "daemon: select: listen=7 busy".
Log file shows:
daemon: select: listen=7 busy
daemon: listen=7, new connection on 30
daemon: activity on 1 descriptor
daemon: waked
daemon: added 30r (active) listener=0
conn=5656 fd=30 ACCEPT from IP=192.168.200.131:40993 (IP=192.168.200.16:9929)
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 2 descriptors
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 30r
daemon: read activity on 30
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: waked
conn=5656 op=0 BIND dn="cn=ldapadmin,dc=abc,dc=com" method=128
daemon: select: listen=7 active_threads=1 tvp=zero
conn=5656 op=0 BIND dn="cn=ldapadmin,dc=abc,dc=com" mech=SIMPLE ssf=0
conn=5656 op=0 RESULT tag=97 err=0 text=
daemon: activity on 1 descriptor
daemon: activity on: 30r
daemon: read activity on 30
daemon: select: listen=7 active_threads=1 tvp=zero
daemon: activity on 1 descriptor
daemon: waked
daemon: select: listen=7 active_threads=1 tvp=zero
conn=5656 op=1 SRCH base="ou=users,dc=abc,dc=com" scope=1 deref=3 filter="(uid=abcservice-prd)"
daemon: activity on 1 descriptor
daemon: select: listen=7 busy
daemon: select: listen=7 busy
daemon: select: listen=7 busy
daemon: select: listen=7 busy
slapd.conf contains
gentlehup on
idletimeout 15
conn_max_pending 10
conn_max_pending_auth 30
My question: How can the problem be solved or reproduced?
The problem comes up in production environment and I need to reproduce it in test environment. How can this be done?
(If the problem can be reproduced with 2.4.22 I will try it with ldap 2.4.24.)
Thanks for any help,
/Frank