389-ds-base

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

Closed: wontfix
Reopen Issue

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 6c43c22c387c4d41fe1689bf73e335e92de8e542

Pushed to 389-ds-base-1.3.3:
6164553..251888e 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 251888e57f2f60fcbe60306e1f489198224f2cae

Pushed to 389-ds-base-1.3.2:
9295966..f3ed96a 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit f3ed96a32f6a5fa4ff09afd36207c1174f29a8a1

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
Metadata
None
None
None
Normal
Community
ack
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.