From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030715 Mozilla Firebird/0.6 Description of problem: U8pon installation of openldap-server, running the command "service ldap starts" logs this in /var/log/messages: Oct 4 06:59:06 rokjor slapd[7847]: ldbm: ==> unable to initialize mutex: Function not implemented Oct 4 06:59:06 rokjor slapd[7847]: ldbm: ==> process-private: unable to initialize environment lock: Function not +implemented Oct 4 06:59:06 rokjor slapd[7847]: ldbm_initialize_env(): FATAL error in dbEnv->open() : Function not implemented (38) Oct 4 06:59:06 rokjor ldap: D�rrage de slapd succeeded Injecting an ldif file gives the following error message: SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database Version-Release number of selected component (if applicable): 2.1.22-6 How reproducible: Always Steps to Reproduce: 1. Install openldap-server on Fedora Core 0.95 2. Run the command "service ldap starts" 3. See contents of /var/log/messages Actual Results: It is not possible to inject LDAP entries in the ldbm database Expected Results: Adding entries should be possible Additional info: The dbEnv->open() line makes me wonder if this isn't a db4 error. Sounds like somebody suffered this on Severn 1 and asked the question on the openldap lists to no avail: http://www.openldap.org/lists/openldap-bugs/200308/msg00024.html Also, this sounds related to another openldap in bugzilla: #90092
What type of CPU is the system on? Which arch/version of glibc is installed (rpm -q --qf '%{name}-%{version}-%{release}-%{arch}\n' glibc)?
The CPU is a Pentium 133 from the Dark Ages (ie 1995). [root@rokjor root]# rpm -q --qf '%{name}-%{version}-%{release}-%{arch}\n' glibc glibc-2.3.2-98-i386 relevant parts of /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 5 model : 2 model name : Pentium 75 - 200 stepping : 11 cpu MHz : 132.634
That's what I suspected. The bundled libdb is unconditionally dependent on NPTL-specific functionality when used by multi-threaded applications like slapd, and NPTL is only part of the i686 version of the glibc package. The openldap-servers-2.1.22-7 package should include both NPTL and non-NPTL bundled libraries, so the ldbm back-end should work again (the bdb back-end absolutely requires it, so you'll need to use an ldbm database). Marking as resolved in that version/release, please reopen if you find that this continues to be a problem.