Bug 90092 - building db-4.1.25 and openldap-2.1.17 breaks with glibc-2.3.2-4
building db-4.1.25 and openldap-2.1.17 breaks with glibc-2.3.2-4
Product: Red Hat Linux
Classification: Retired
Component: db4 (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-05-02 08:55 EDT by Gerald Carter
Modified: 2007-04-18 12:53 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-13 17:51:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace output from failed slapadd (4.11 KB, application/octet-stream)
2003-05-09 16:59 EDT, Gerald Carter
no flags Details

  None (edit)
Description Gerald Carter 2003-05-02 08:55:18 EDT
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):

How reproducible:

Steps to Reproduce:
see above comments.

Expected Results:  db backend files should have been created by the slapadd run.

Additional info:
Comment 1 Ulrich Drepper 2003-05-06 23:53:46 EDT
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.
Comment 2 Gerald Carter 2003-05-09 16:59:48 EDT
Created attachment 91597 [details]
strace output from failed slapadd
Comment 3 Gerald Carter 2003-05-09 17:03:17 EDT
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)'

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)

Comment 4 matti aarnio 2003-06-12 06:59:37 EDT
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.
Comment 5 Ulrich Drepper 2003-10-02 01:50:49 EDT
db4 problem.  O_DIRECT isn't used in recent versions anymore AFAIK.
Comment 6 Jeff Johnson 2003-12-13 17:51:26 EST
Fixed in db-4.2.52, which disables O_DIRECT on linux.

Note You need to log in before you can comment on or make changes to this bug.