Bug#360696: [exim] Bug#360696: Failed to get write lock for /var/spool/exim4/db/retry.lockfile:timedout

[Andreas Metzler]

On 2006-04-28 Michel Meyers <steltek at tcnnet.com> wrote:
> Philip Hazel wrote:
[...]
>> (gdb) where
>> #0  0xffffe410 in ?? ()
>> #1  0xbfd18ce8 in ?? ()
>> #2  0xb7ab6ff4 in ?? ()
>> #3  0xbfd18d0c in ?? ()
>> #4  0xb7a44313 in ?? ()
>> #5  0xb7e78cb0 in ?? () from /usr/lib/libdb-4.2.so
>> #6  0xbfd18d78 in ?? ()
>> #7  0xb7e5ffb2 in __memp_set_ftype_4002 () from /usr/lib/libdb-4.2.so
>> #8  0xb7e5ffb2 in __memp_set_ftype_4002 () from /usr/lib/libdb-4.2.so
>> #9  0xb7e459ce in __dbenv_set_flags_4002 () from /usr/lib/libdb-4.2.so
>> #10 0xb7e2cfff in __db_c_put_4002 () from /usr/lib/libdb-4.2.so
>> #11 0xb7e28990 in __db_pg_free_read_4002 () from /usr/lib/libdb-4.2.so
>> #12 0x080616b2 in dbfn_open (name=0x80f1ad1 "retry", flags=2,
>>     dbblock=0x812d498, lof=1) at dbfn.c:166
>> #13 0x0809da66 in retry_update (addr_defer=0x810bf18, addr_failed=0x810bf14,
>>     addr_succeed=0x810bf04) at retry.c:599
>> #14 0x0806b61d in deliver_message (id=0x81244d5 "1FYpIF-0006Rh-NB", forced=0,
>>     give_up=0) at deliver.c:6086
>> #15 0x0808fc8a in queue_run (start_id=0x0, stop_id=0x0, recurse=0)
>>     at queue.c:621
>> #16 0x08072c0e in main (argc=<value optimized out>, cargv=0xbfd59bc4)
>>     at exim.c:3878

>> If that backtrace is to be trusted, Exim's function dbfn_open() has
>> called the function __db_pg_free_read_4002() from the libdb library, and
>> somewhere in there is where things get stuck. Of course, Exim doesn't
>> call such a function by a name like that. It will be using the "open"
>> function pointer in the data structure it gets from db_create().

>> There have been several releases of libdb-4.2 (I'm running 4.2.52). I
>> wonder what you are running?

> I've got 4.2.52-23.1.

>> Anyway, this looks like something really horrid going on inside libdb. I
>> am not at all sure what we do now. Andreas?

> Good question. Either this is something wrong with my system (HDD
> corruption?) or the Debian bug needs to go to the maintainer of libdb4.2
> for further handling.

It might be a good idea to check whether the retry db is corrupted and
makes libdb break. - Moving away /var/spool/exim4/db/* (but not
deleteting them, they might be useful for debugging) would accomplish
that. If that failed the logical next step would be to check if e.g.
libdb 4.4 also shows the bug.

cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde