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.
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.
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.
*** Bug 88178 has been marked as a duplicate of this bug. ***
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
Also see bug # 88456. There is a possible solution mentioned there (a kludgy workaround in my opinion).
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?
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 :)
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).
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
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?
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
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.
This will be resolved the same way as #91933, hence a duplicate. *** This bug has been marked as a duplicate of 91933 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.