Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 86381 - db4 not functional on non-NPTL kernel?
Summary: db4 not functional on non-NPTL kernel?
Keywords:
Status: CLOSED DUPLICATE of bug 91933
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: db4
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-20 22:36 UTC by Simon Matter
Modified: 2007-04-18 16:52 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-21 18:52:15 UTC


Attachments (Terms of Use)
Strace of sample program after using glibc-2.3.2....i386.rpm (deleted)
2003-04-16 22:05 UTC, Iustin Pop
no flags Details

Description Simon Matter 2003-03-20 22:36:10 UTC
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 22:05:39 UTC
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 08:52:59 UTC
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 08:56:09 UTC
*** Bug 88178 has been marked as a duplicate of this bug. ***

Comment 4 Joe Orton 2003-04-27 16:14:54 UTC
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 14:33:35 UTC
Also see bug # 88456.  There is a possible solution mentioned there (a kludgy
workaround in my opinion).

Comment 6 Simon Matter 2003-05-16 13:25:54 UTC
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 15:26:59 UTC
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 10:14:40 UTC
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 17:47:30 UTC
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 11:44:37 UTC
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 06:55:38 UTC
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-07 04:30:59 UTC
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 23:09:17 UTC
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 18:52:15 UTC
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.