On Tue, 2 Sep 2003, Liz Sandland wrote:
> Users' mail is delivered to an NFS mounted mailbox.
> Following an NFS server crash, inbound mail is now queueing up on our
> mailhub. I've tried restarting exim but the fault persists. The fault is
> that if I try to deliver a message exim reports "spool file is locked".
> I can see the .lock file is created at this time but unless it is
> removed by hand, it remains.
"Spool file is locked" means that Exim's spool file is locked. This is
not the mailbox file, and .lock isn't relevant. It means another Exim
process is working on the message. Restarting the Exim daemon won't
help, because it's a delivery process.
> It looks like I have a problem with stuck processes. Although the
> FAQ/mailing list archive have allowed me to identify that the problem is
> that the process that is delivering the message has 'somehow got stuck',
> there doesn't seem to be any advice on how to proceed. I don't want to
> lose the incoming mail but would like to know if I can safely remove any
> files from the spool dir before retrying delivery.
Don't remove any files from the spool dir (/var/spool/exim). They *are*
the messages. However, you can safely kill the stuck delivery processes.
You should be able to identify them using exiwhat.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
