At 02:37 PM 2/22/2001, Philip Hazel wrote:
>On Thu, 22 Feb 2001, Todd Jagger wrote:
>
> > # /usr/exim/bin/exim_tidydb /usr/exim/spool wait-remote_smtp
> > Exim wait-remote_smtp database in spool /usr/exim/spool
> > Failed to get write lock for
> > /usr/exim/spool/db/wait-remote_smtp.lockfile: timed out
>
>*Some* process has the file
>/usr/exim/spool/db/wait-remote_smtp.lockfile
>open and locked. Does your operating system have tools for finding
>processes that have certain files open? There are such things, but I
>forget the command names. It would be of interest to know what was
>holding it open for such a long time, because Exim should only lock it
>
>very briefly.
>
>If you can't find out what's holding it open, you could try removing
>it.
>Exim will create a new one, which will be a different file.
Thanks Philip,
For some reason one of the attempts to refuse a spam was holding on to
the file, I guess:
(This will probably word-wrap very funky...)
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
exim 23993 99.8 0.5 1728 1196 ? R Feb 20 3636:03
/usr/exim/bin/exim -Mc 14V8IU-0006Ey-00
Looking at the message showed it to be some bogus address.
Not sure why that one hung in there but removing the lock file didn't
make it better. After that I got these messages:
2001-02-22 15:41:45 14W3Ue-0002dd-00 failed to open DB file
/usr/exim/spool/db/wait-remote_smtp: Try again
A lock file was back in but those error messages repeated.
However, stopping exim, flushing the mailq, removing the lock file
again, and specifically killing that pid referenced above made
everything happy again upon restart. Probably just killing the pid
would've done it, I'll bet.
Thanks again,
Todd
