Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1155680
Description of problem: /usr/sbin/setup-ds-admin.pl fails with Error: failed to open an LDAP connection to host 'example.org' port '389' as user 'cn=Directory Manager'. Error: unknown. ns-slapd is running and listening on port 389. Running /usr/sbin/setup-ds-admin.pl under strace -f shows that it gets a connection refused error, while connecting to a correct example.org IP address. Problems: 1. message says "Error: unknown" instead of "Error: connection refused" 2. /usr/lib/dirsrv/perl/DSCreate.pm diligently reads ns-slapd log file and waits for 'slapd started.' message. However ns-slapd puts out 'slapd started.' message shortly before it really starts accepting connections. Workaround: add a several seconds delay after debug(1, "Your new directory server has been started.\n"); line. Version-Release number of selected component (if applicable): Probably all before and including 389-ds-base-1.3.2.23-1.fc20, since forums and mailing lists mention this error since at least 2009 with no solution offered. How reproducible: there is a sufficient chance of getting the error on Intel(R) Pentium(R) 4 CPU 3.00GHz system. Steps to Reproduce: 1. create an ldap parameters file and repeatedly run /usr/sbin/setup-ds-admin.pl --debug --silent --force --file=/path/to/ldap.txt then systemctl stop dirsrv.target and rm -rf /etc/dirsrv/slapd-name and /var/lib/dirsrv/slapd-name after each run, where name is configured ldap server name. Actual results: Error sometimes occur. Expected results: No errors should occur.
We should investigate why the directory server prints "slapd started." when it is not yet available to respond to clients, and change it. We need to have some way to tell when the server is available without the client having to poll on the listen port.
Replying to [comment:1 rmeggins]:
Indeed, we are printing "slapd started." before calling PR_Listen.
{{{ 936 void slapd_daemon( daemon_ports_t ports ) 937 { [...] 1011 unfurl_banners(the_connection_table,ports,n_tcps,s_tcps,i_unix); <== print "slapd started. Listening on ..." message [...] 1066 / We are now ready to accept incoming connections / 1081 if ( n_tcps != NULL ) { 1082 PRFileDesc fdesp; 1083 PRNetAddr nap = ports->n_listenaddr; 1084 for (fdesp = n_tcps; fdesp && fdesp && nap && nap; fdesp++, nap++) { 1085 if ( PR_Listen( fdesp, config_get_listen_backlog_size() ) == PR_FAILURE ) { [...] }}}
I moved the line 1011 after calling PR_Listen on all the configured ports and ran silent install without any problems. Do we want to make this change?
I think we should move unfurl_banners() to just after write_pid_file(), just before the while(!g_get_shutdown()) call. The presence of the pid file is also supposed to mean the server is ready and listening for connections.
Replying to [comment:3 rmeggins]:
Thanks, Rich! Makes sense.
git patch file (master) 0001-Ticket-47935-Error-failed-to-open-an-LDAP-connection.patch
Reviewed by Rich (Thank you!!)
Pushed to master: 4a5eee6..6c43c22 master -> master commit 6c43c22
Pushed to 389-ds-base-1.3.3: 6164553..251888e 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 251888e
Pushed to 389-ds-base-1.3.2: 9295966..f3ed96a 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit f3ed96a
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.2.24
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1266
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.