#47935 Error: failed to open an LDAP connection to host 'example.org' port '389' as user 'cn=Directory Manager'. Error: unknown.
Closed: wontfix None Opened 7 years ago by rmeggins.

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]:

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.

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]:

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.

Thanks, Rich! Makes sense.

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

5 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.

Metadata