Re: [exim] Bug#360696: Bug#360696: Failed to get write lock …

Top Page
Delete this message
Reply to this message
Author: Michel Meyers
Date:  
To: exim-users
CC: 360696-quiet, Andreas Metzler
Subject: Re: [exim] Bug#360696: Bug#360696: Failed to get write lock for /var/spool/exim4/db/retry.lockfile:timedout
Philip Hazel wrote:
> On Fri, 28 Apr 2006, Michel Meyers wrote:
>
> 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?
>
> Anyway, this looks like something really horrid going on inside libdb. I
> am not at all sure what we do now. Andreas?


OK, an update from my side: I never really tried anything on those retry
files but with the above information I went into /var/spool/exim4/db and
found a file called __db.retry, some .lockfiles with 0 bytes size and
some wait-* files (wait-amavis and wait-remote_smtp to be exact).

The wait-* files are 12288 bytes in size, the __db.retry one 4096. Just
for the sake of it, I shut down exim and moved __db.retry out of the
way. When I restarted exim, nothing happened at first until I tried to
deliver to my favourite greylisting server again.

End result: Exim created a file called 'retry' (not __db.retry) and
guess what size it has? Correct: 12288 bytes. My exim thread doesn't
lock up on retry any more either.

So there you have it: deleting one silly little file fixed my months old
issue (if only I had tried that before!).

Anyway, thanks for all your time and great support. Hopefully I won't
have to bother you again anytime soon.

Greetings,
        Michel