From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 Description of problem: building db-4.1.25 from sleepycat.com on a patched RH 8.0 system (RPMS from redhat.com) builds fine. OpenLDAP-2.1.17 builds fine as well. However, when any openldap server or tool tries to create a new database for the initial install, the db_env->open() fails with EINVAL. (see openldap-2.1.17/servers/slapd/back-bdb/init.c (line 301)). I've traced this into the db-4.1 libraries and the failure is a write() call on a file opened with O_CREAT|O_RDWR|O_EXCL|O_DIRECT. If the db-4.1.25 libraries are built on on a RH 8.0 box (no patches) the openldap installation suceeds without any problems. The database is created as expected. (slapadd -v -l <ldif file>) db-4.1.25 built with no flags to configure (other than --prefix=/usr/local). Openldap built with env CFLAGS="-g" ./configure \ --sysconfdir=/etc \ --enable-bdb \ --with-slurpd \ --enable-wrappers \ --enable-ipv6 \ --enable-ldap \ --enable-rewrite \ --enable-meta \ This problem is not seen on a patched RH 7.3 or a stock RH 9 box. Building the db libraries on an unpatched RH 8.0 box and installing them on the patched box (with glibc 2.3.2-4) works around the problem. Version-Release number of selected component (if applicable): glibc-2.3.2-4 How reproducible: Always Steps to Reproduce: see above comments. Expected Results: db backend files should have been created by the slapadd run. Additional info:
write() is a wrapper around a system call. There cannot be anything wrong with it. Since the code is using O_DIRECT my guess is that this feature is used incorrectly. Run strace on the program which fails and attach the output to this bug.
Created attachment 91597 [details] strace output from failed slapadd
Reproduced on RH 9 system with 2.4.20 kernel from kernel.org (no patches). New kernel due to ptrace problems with RH 9 one. garion:/var/ldap/garion# uname -a Linux garion 2.4.20 #1 Fri May 9 14:03:58 CDT 2003 i686 i686 i386 GNU/Linux # rpm -qa | egrep '(kernel|glibc)' glibc-2.3.2-11.9 kernel-2.4.20-8 glibc-kernheaders-2.4-8.10 glibc-devel-2.3.2-11.9 kernel-pcmcia-cs-3.1.31-13 glibc-common-2.3.2-11.9 kernel-source-2.4.20-8 open("/var/ldap/garion/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0600) = 6 fcntl64(6, F_SETFD, FD_CLOEXEC) = 0 _llseek(6, 0, [0], SEEK_END) = 0 _llseek(6, 8192, [8192], SEEK_CUR) = 0 write(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = -1 EINVAL (Invalid argument)
The problem is indeed in use of O_DIRECT: open("/opt/mail/db/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0600) = 5 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 open("/opt/mail/db/__db.001", O_RDWR|O_CREAT|O_DIRECT|O_LARGEFILE, 0600) = 5 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 _llseek(5, 0, [0], SEEK_END) = 0 _llseek(5, 8192, [8192], SEEK_CUR) = 0 write(0x5, 0xbff26bf0, 0x2000) = -1 (errno 22) In Linux it adds mandatory requirement for the write to happen out from PAGE ALIGNED memory area. Apparently the lattest version of rawhide db4-4.1.25-3 SRC package has an autoconfig test that recognizes this issue, and _in_the_compile_machine_ does see if O_DIRECT does work as BSD expects it to (FreeBSD man pages are "somewhat" vague about it, so is Linux man-page). Now if compilations are done at a machine with older kernel (and/or libraries), then very likely kernel just ignores the option, and a binary is produced, which will use O_DIRECT option --> resulting binary RPM package fails to function.
db4 problem. O_DIRECT isn't used in recent versions anymore AFAIK.
Fixed in db-4.2.52, which disables O_DIRECT on linux.