Hi, with OpenLDAP 2.4.22 on Solaris 10 we discovered following situation: from time to time the slapd log file contains message "daemon: select: listen=7 busy" while ldap continues to operate normally.
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
Frank Budde wrote:
Hi, with OpenLDAP 2.4.22 on Solaris 10 we discovered following situation: from time to time the slapd log file contains message "daemon: select: listen=7 busy" while ldap continues to operate normally.
Sounds similar to this http://www.openldap.org/its/index.cgi/Incoming?id=6833
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
openldap-technical@openldap.org