Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 7454 - elm/NFS-mounted spool locking problem
Summary: elm/NFS-mounted spool locking problem
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: elm
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-30 21:57 UTC by bonnevil
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-29 14:34:20 UTC

Attachments (Terms of Use)

Description bonnevil 1999-11-30 21:57:59 UTC
I'm having a locking problem when attempting to use elm-2.5.1-1.i386.rpm
(Red Hat 6.1) to read a spool file mounted via NFS.  It looks like elm is
trying to use flock to make the lock, which is probably wrong:

  Cannot flock folder "/var/spool/mail/jrandom"! [No locks available]

The kernel syslogs:

  Nov 30 14:37:48 grun kernel: lockd: failed to monitor xxx.xx.x.xx
                            (IP address of NFS server) -^^^^^^^^^^^

I've downloaded elm-2.5.2 source from and attempted to
build it, but I noticed that the Configure script doesn't seem to be
able to see fcntl locking support under RH 6.1.  Here's that bit:

Configure script looks for F_SETLK definition in
  /usr/include/sys/fcntl.h                (file present on RH 6.1)
  /usr/include/sys/file.h                 (file present on RH 6.1)
  /usr/include/fcntl.h                    (file present on RH 6.1)

Under Red Hat 5.2, F_SETLK was defined in /usr/include/fcntlbits.h, but
it's now defined in /usr/include/bits/fcntl.h instead, and the old file
has been removed.

I patched Configure so that it found F_SETLK, but I still get the same
error once the program is compiled.  I told Configure to compile with
support for fcntl and dot-locking.  Was not prompted for flock at all;
saw "flock() found." then "flock locking not available" in Configure.

I can reproduce the problem in Magic mode (-M) when reading any mail
folder with (elm -M -f somemailfile) on a NFS mounted directory.  If
I move the same file to a local directory and try the same command,
it works correctly.

I'm open to suggestions to make this work -- I've got a lot of people
using elm-2.4 to read mail via NFS with Red Hat 5.2 successfully, and
I'd like to upgrade them to RH 6.1.  Thanks.

  Steve Bonneville
  IMA System Administrator
  University of Minnesota

--- Configure   Tue Nov 30 13:34:07 1999
+++ Configure.orig      Tue Nov 30 11:37:15 1999
@@ -2619,9 +2619,6 @@
 elif $contains F_SETLK /usr/include/fcntlbits.h >/dev/null 2>&1; then
     echo 'F_SETLK found, fcntl locking available'
-elif $contains F_SETLK /usr/include/bits/fcntl.h >/dev/null 2>&1; then
-    echo 'F_SETLK found, fcntl locking available'
-    has_fcntl="$define"
     echo 'F_SETLK not found, fcntl locking not available'

Comment 1 bonnevil 1999-12-01 15:27:59 UTC
Communicated with Bill Pemberton (elm maintainer,
and did further investigation.  It appears that NFS locking had at
some point been turned off on my clients; with statd/lockd running on
the clients properly elm works.  That fixes my main problem.

He also told me that elm-2.5.3 (unreleased) has included a fix similar
to the one I included above for the Configure script in 2.5.2.  I did
not look at the SRPM to see if the change is also there.

Locking seems to have changed from RH 5.2 (dot-locks only) to fcntl
only -- if there's no reason not to, it might be good to configure
both dot-locking and fcntl support.

Comment 2 Jeff Johnson 1999-12-01 15:34:59 UTC
The goal since Red Hat 5.2 has been to use *only* fcntl locking in MTA/MUA.

Comment 3 Jeff Johnson 2000-02-29 14:34:59 UTC
elm-2.5.3 is in Raw Hide and will be in Red Hat 6.2, and contains a patch
identical to yours above.

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