cyrus-murder problems with database corruption in the frontend/master

João Assad jfassad at
Fri Apr 8 21:12:07 EDT 2005

João Assad wrote:

> Derrick J Brashear wrote:
>> On Fri, 8 Apr 2005, João Assad wrote:
>>> João Assad wrote:
>>>> Managed to get a backtrace using debug_command ( thanks for this 
>>>> nifty feature Henrique de Moraes )
>>> 2 gdb backtraces from the production server.
>> curiously, the strace output isn't showing an mmap() call fail, that 
>> I see, before the error shows up.
> Yeah I noticed that too. thats because strace attached to the main 
> thread and is not tracing threads forked by it.
> Im doing some tests using strace -ff now , to follow all forked 
> threads and I see the mmaps there... but it makes cyrus too slow
> and thats causing all sorts of weird behaving on futex
> futex(0x8101c64, FUTEX_WAIT, 772, {59, 999828000}) = -1 ETIMEDOUT 
> (Connection timed out)
> futex(0x8101c60, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource 
> temporarily unavailable)
I could do a strace -f wich would dump all the traces from all the 
threads into a single file... but its a nightmare to read it.
by reading some strace output here I've noticed mmaps complaining about 
ENOMEM way before the mmap inside map_refresh goes crazy.
then It came to me that cyrus only do mmap inside map_refresh and It 
seemed to me that it was tcp_wrappers mmap that was causing the rist ENOMEM

Im trying to recompile without tcp_wrappers and check if I can clean 
strace output a bit.

Cyrus Home Page:
Cyrus Wiki/FAQ:
List Archives/Info:

More information about the Info-cyrus mailing list