Bug 90092 - building db-4.1.25 and openldap-2.1.17 breaks with glibc-2.3.2-4
Summary: building db-4.1.25 and openldap-2.1.17 breaks with glibc-2.3.2-4
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: db4   
(Show other bugs)
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-02 12:55 UTC by Gerald Carter
Modified: 2007-04-18 16:53 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-13 22:51:26 UTC
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 20:59 UTC, Gerald Carter
no flags Details

Description Gerald Carter 2003-05-02 12:55:18 UTC
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-07 03:53:46 UTC
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 20:59:48 UTC
Created attachment 91597 [details]
strace output from failed slapadd

Comment 3 Gerald Carter 2003-05-09 21:03:17 UTC
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 10:59:37 UTC
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 05:50:49 UTC
db4 problem.  O_DIRECT isn't used in recent versions anymore AFAIK.

Comment 6 Jeff Johnson 2003-12-13 22:51:26 UTC
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.