Bug 52278 - locks remain forever after client crash
locks remain forever after client crash
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Depends On:
  Show dependency treegraph
Reported: 2001-08-22 07:28 EDT by Alexandre Oliva
Modified: 2007-04-18 12:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-11 06:46:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2001-08-22 07:28:04 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010808

Description of problem:
At the university, our e-mail server was recently moved from a Solaris box
to a Red Hat Linux 7.1 box.  Ever since, some users have experienced mail
delivery delays.  We use sendmail+procmail for e-mail delivery on the Red
Hat Linux box.  /var/spool/mail is exported to a number of NFS clients, so
that users can keep on using mailtool on Solaris, and other MUAs on Solaris
or Red Hat Linux that access mailboxes in /var/spool/mail.

The problem is that, sometimes, after some client or gateway machine
crashes, mailboxes remain locked, and procmail is no longer able to deliver
e-mail to these mailboxes, blocking delivery of the message not only to
that particular user, but also to many other recipients of the same message.

lslk shows mailboxes are locked by remote processes, but the clients that
used to hold the lock no longer believe to do so: oftentimes, the client
itself was rebooted or went down due to power failure; other times, it may
have been a gateway between the server and the client that remained down
for an extended period of time.

Anyway, the point is that there are only two ways to get e-mail delivery to

(i) reboot the server, so that the lock state is reset after clients are

(ii) copy the locked mailbox file to a new file and (atomically?) rename
the new file to the old one then kill sendmail and procmail waiting for the
lock.  The lock remains, but in a removed file, so it no longer gets in the

I suppose there's something wrong with lock recovery on remounting, or on
lock time-outs, or I'm missing something about NFS locking.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Set up mail delivery at a Red Hat Linux 7.1 box with sendmail and procmail
2.Export /var/spool/mail and let users use tools that acquire locks on
mailbox files
3.Let clients crash, freeze or lose contact to the server for extended 
periods of time
4.Expect complains from users that they're no longer getting e-mail.
5.Verify with strace that procmail is waiting for a lock, and check with
lslk that the lock is held by a remote process, that is no longer there.


Actual Results:  The lock is never released, requiring manual intervention.

Expected Results:  When the client re-connects, the server should attempt
to release the lock.

Additional info:
Comment 1 Steve Dickson 2004-08-11 06:46:52 EDT
Some patches when into later kernel that should take care of 
this issue.

Note You need to log in before you can comment on or make changes to this bug.