Bug 86381 - db4 not functional on non-NPTL kernel?
db4 not functional on non-NPTL kernel?
Status: CLOSED DUPLICATE of bug 91933
Product: Red Hat Linux
Classification: Retired
Component: db4 (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-20 17:36 EST by Simon Matter
Modified: 2007-04-18 12:52 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:52:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Strace of sample program after using glibc-2.3.2....i386.rpm (2.03 KB, text/plain)
2003-04-16 18:05 EDT, Iustin Pop
no flags Details

  None (edit)
Description Simon Matter 2003-03-20 17:36:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030206

Description of problem:
I have installed phoebe-3 on my test box, which is an AMD K6-2/400, and rebuilt
my cyrus-imapd rpm from http://home.teleport.ch/simix/. When starting
cyrus-imapd, I get many db errors. I have then installed phoebe-3 on another
computer, PII/400, and rebuilt the cyrus-imapd rpm there and everything works
fine. I have then reinstalled phoebe-3 on the AMD again and rebuilr cyrus-imapd
too and still get the same errors. The same cyrus-imapd rebuilt on RedHat 6.2 on
the same AMD K6-2 works without any problem.

Version-Release number of selected component (if applicable):
db4-4.0.14-20

How reproducible:
Always

Steps to Reproduce:
1. Install phoebe-3
2. rpmbuild --rebuild cyrus-imapd-2.1.x-x.src.rpm
3. service cyrus-imapd start

    

Actual Results:  Mar 20 23:30:45 black master[2104]: process started
Mar 20 23:30:45 black ctl_cyrusdb[2105]: recovering cyrus databases
Mar 20 23:30:45 black ctl_cyrusdb[2105]: DBERROR db4: /var/lib/imap/db/__db.001:
unable to initialize environment lock: Function not implemented
Mar 20 23:30:45 black ctl_cyrusdb[2105]: DBERROR: dbenv->open '/var/lib/imap/db'
failed: Function not implemented
Mar 20 23:30:45 black ctl_cyrusdb[2105]: DBERROR: init /var/lib/imap/db: cyrusdb
error
Mar 20 23:30:45 black ctl_cyrusdb[2105]: DBERROR: reading
/var/lib/imap/db/skipstamp, assuming the worst: No such file or directory
Mar 20 23:30:45 black cyrus-imapd: cyrus-master startup succeeded
Mar 20 23:30:45 black ctl_cyrusdb[2105]: skiplist: recovered
/var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds
Mar 20 23:30:45 black ctl_cyrusdb[2105]: done recovering cyrus databases
Mar 20 23:30:45 black master[2104]: process 2105 exited, status 1
Mar 20 23:30:45 black master[2104]: ready for work
Mar 20 23:30:45 black ctl_cyrusdb[2113]: checkpointing cyrus databases
Mar 20 23:30:45 black ctl_cyrusdb[2113]: DBERROR db4: /var/lib/imap/db/__db.001:
unable to initialize environment lock: Function not implemented
Mar 20 23:30:45 black ctl_cyrusdb[2113]: DBERROR: dbenv->open '/var/lib/imap/db'
failed: Function not implemented
Mar 20 23:30:45 black ctl_cyrusdb[2113]: DBERROR: init /var/lib/imap/db: cyrusdb
error
Mar 20 23:30:45 black ctl_cyrusdb[2113]: done checkpointing cyrus databases
Mar 20 23:30:46 black imapd[2114]: DBERROR: reading /var/lib/imap/db/skipstamp,
assuming the worst: No such file or directoryMar 20 23:30:46 black lmtpd[2118]:
DBERROR db4: /var/lib/imap/db/__db.001: unable to initialize environment lock:
Function not implemented
Mar 20 23:30:46 black lmtpd[2118]: DBERROR: dbenv->open '/var/lib/imap/db'
failed: Function not implemented
Mar 20 23:30:46 black lmtpd[2118]: DBERROR: init /var/lib/imap/db: cyrusdb error
Mar 20 23:30:46 black lmtpd[2118]: lmtpd: unable to init duplicate delivery database
Mar 20 23:30:46 black lmtpd[2118]: DBERROR: reading /var/lib/imap/db/skipstamp,
assuming the worst: No such file or directoryMar 20 23:30:46 black imapd[2115]:
DBERROR: reading /var/lib/imap/db/skipstamp, assuming the worst: No such file or
directoryMar 20 23:30:46 black pop3d[2116]: DBERROR: reading
/var/lib/imap/db/skipstamp, assuming the worst: No such file or directoryMar 20
23:30:46 black pop3d[2117]: DBERROR: reading /var/lib/imap/db/skipstamp,
assuming the worst: No such file or directoryMar 20 23:30:46 black imapd[2114]:
skiplist: recovered /var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds
Mar 20 23:30:46 black lmtpd[2118]: skiplist: recovered
/var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds
Mar 20 23:30:46 black imapd[2115]: skiplist: recovered
/var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds
Mar 20 23:30:46 black pop3d[2116]: skiplist: recovered
/var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds
Mar 20 23:30:46 black pop3d[2117]: skiplist: recovered
/var/lib/imap/mailboxes.db (1 record, 280 bytes) in 0 seconds

Expected Results:  No dberrors should show up.

Additional info:

I have really no idea where the problem is. I had RedHat 8.0 on the same box on
the same partitions before and never had any problem. On the other side I really
don't understand why those errors don't show up on i686 class computers. I got
reports from people who tested my cyrus-imapd on phoebe-3 too without any problem.
Comment 1 Iustin Pop 2003-04-16 18:05:39 EDT
Created attachment 91162 [details]
Strace of sample program after using glibc-2.3.2....i386.rpm

I experience the same problem with redhat 9 on ADM Duron; www.kernel.org 2.4.20
+ xfs patches, other that that standard rh9 + updates
(glibc-2.3.2-27.9.i686.rpm)

The problem can be generated by this simple program:
#include <db.h>
									       
						  
int main() {
    DB_ENV *e;
    int ret;
									       
						  
    if((ret = db_env_create(&e, 0)) != 0) {
	e->err(e, ret, "In db_env_create");
    }
    if((ret = e->open(e, "/tmp/m", DB_INIT_LOCK | DB_CREATE | DB_INIT_MPOOL,
0666)) != 0) {
	e->err(e, ret, "In dbenv->open");
    }
									       
						  
}
which gives the following (/tmp/m directory exists):
In dbenv->open: Function not implemented

I traced this problem to the lock initialization phase, more precisely in the
source of db4, file 'mutex/mut_pthread.c', somewhere in function
__db_pthread_mutex_init, but I can't understand why it behaves like that.

While testing with glibc from updates but for i386 (not i686), every program
gives Segmentation fault (I can't even start a new xterm now... :).

The strace right before segv is:
open("/lib/i686/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200A\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=93268, ...}) = 0
old_mmap(NULL, 325088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40208000
old_mmap(0x40215000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xd000) = 0x40215000
old_mmap(0x40218000, 259552, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40218000
close(3)				= 0
munmap(0x40014000, 78316)		= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

So this could be about pthreads and stuff. Using LD_ASSUME_KERNEL=2.2.5 gets
rid of the sisegv, but says: function not implemented.
Comment 2 Joe Orton 2003-04-27 04:52:59 EDT
This looks similar to bug 88178: I think the problem is that DB4 is configured
to use pthread mutexes in Shrike, but this depends on
pthread_mutexattr_setpshared working.  But it seems pthread_mutexattr_setpshared
only works with an NPTL-savvy kernel, so DB4 doesn't work right of booting an
old (or non-NPTL) kernel.
Comment 3 Joe Orton 2003-04-27 04:56:09 EDT
*** Bug 88178 has been marked as a duplicate of this bug. ***
Comment 4 Joe Orton 2003-04-27 12:14:54 EDT
A simple repro case for this is 

  $ rm -rf /tmp/foobar
  $ LD_ASSUME_KERNEL=2.2.5 svnadmin create /tmp/foobar
  svn: Berkeley DB error
  svn: Berkeley DB error while creating environment for filesystem /tmp/foobar/db:
  Function not implemented
Comment 5 Mobeen Azhar 2003-04-28 10:33:35 EDT
Also see bug # 88456.  There is a possible solution mentioned there (a kludgy
workaround in my opinion).
Comment 6 Simon Matter 2003-05-16 09:25:54 EDT
I'm still getting questions from people using my cyrus-imapd rpms on AMD
K6/Athlon CPU's, where it doesn't work. Does anybody at redhat pay attention to
this bug?
Comment 7 Mobeen Azhar 2003-05-16 11:26:59 EDT
Simon, I am not sure if anyone from RedHat is paying any attention to this bug.
 Another bug, #88456, has been open for quite some time which references the
root cause of this problem, and so far I have not gotten anything definite on it
from RedHat.  I am not sure if they are just not paying attention or the issue
is too deep for them to come up with a quick (under 2 month) answer.

BTW, thanks a million in keeping up with the good work with RPM maintenance of
the Cyrus RPMS :)
Comment 8 Joe Orton 2003-05-18 06:14:40 EDT
The root cause of the problem is as above: the db4 package shipped in Shrike only
works correctly when you boot a kernel which has NPTL support, for example the
kernel included in Shrike.  This bug manifests itself when you boot some other
kernel (something which is not really supported).
Comment 9 Mobeen Azhar 2003-05-18 13:47:30 EDT
Actually NPTL support not in the kernel but in glibc.  RedHat seems to have
messed up the glibc pieces pretty well.  Pretty well discussed in bug $ 88456
Comment 10 Simon Matter 2003-05-19 07:44:37 EDT
To Joe Orton,
If I had recompiled my own kernel or glibc, I understand that this was an 
unsupported configuration. But it happens with the kernel and glibc package 
which is installed by the installer. I didn't modify anything. So I still 
consider this a real bug. I reported that AMD K6 CPU's are affected but I got 
reports from other people with Athlon and Pentium I CPU's which are affected 
too. Some of them have now downgraded to RedHat 8.0 but that's not a real 
solution. Is there anything I could try to help resolving the issue?
Comment 11 Simon Matter 2003-06-02 02:55:38 EDT
Well, because nobody seems to really care about this issue, I propose the
following solution until we get an official fix.
Just rebuild db4 with the following .spec file which removes
--enable-posixmutexes. The resulting rpms work fine on any non i686 RedHat 9
installation. YMMV.

http://home.teleport.ch/simix/RPMS/Cyrus-imapd/DB4_for_RH-9/db4.spec
Comment 12 Nathan G. Grennan 2003-11-06 23:30:59 EST
Odd, I have been running cyrus-imapd with RH9' db4 quite happy on an
Athlon server. I have tried to upgrade the kernel to a rawhide kernel
recently and think I ran into this problem. It seemed to me I needed
db4 from rawhide, which required new versions of many things so I
backed off on the kernel. I am planning on upgrading the to Fedora
Core 1 soon and hope I don't run into such issues.
Comment 13 Jeff Johnson 2003-12-13 18:09:17 EST
This will be resolved the same way as #91933, hence a duplicate.

*** This bug has been marked as a duplicate of 91933 ***
Comment 14 Red Hat Bugzilla 2006-02-21 13:52:15 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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