Bug 11431 - mutt cannot lock NFS mounted mailfiles
Summary: mutt cannot lock NFS mounted mailfiles
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mutt   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-05-16 03:47 UTC by benjamin-redhat
Modified: 2014-03-17 02:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-16 16:09:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description benjamin-redhat 2000-05-16 03:47:24 UTC
First, I doubt that this is a problem with mutt, but rather with the NFS
locking, but I was not able to verify this yet, so am starting with mutt,
which is the only program with which I had this problem until now.

The /home/common partition is mounted via NFS. With a plain RedHat 6.1
install, if I access any mailbox which resides within this partition, mutt
is unable to lock it:

If no NFS daemon is started on the local host (my default), I get the
following strace:

open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3
SYS_175(0, 0x80a1320, 0, 0x8, 0)        = 0
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1
ENOLCK (No locks available)

and mutt writes out an appriopriate error message (sometimes it gets
overwritten at once by some other status messages, so it is not always
visible, but you can hear the bell, too).

If I start /etc/rc.d/init.d/nfs (I tried this, due to some seemingly
unrelated tips to other NFS problems) the behaviour changes: I can see the
status line "Waiting for fcntl lock... 1" which counts in second-steps up
to 5 and finally I get the message "Timeout exceeded while attempting fcntl
lock", which corresponds with the following strace:

open("/home/common/benjamin/Mail/igg", O_RDONLY) = 3
SYS_175(0, 0x80a8848, 0, 0x8, 0)        = 0
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1
EACCES (Permission denied)
fstat(3, {st_mode=0, st_size=0, ...})   = 0
brk(0x80c5000)                          = 0x80c5000
write(1, "\r\33[30m\33[47mWaiting for fcnt"..., 53^MESC[30mESC[47mWaiting
for fcntl lock... 1ESC[KESC[39;49mESC[m^O) = 53

Some notes:
- the problem seems to be NFS related: if I do
  sudo cp -a /home/common/benjamin /home/common, the problem is gone
- the rights on my mailboxes seem to be ok:
  I have no problem to read the same folder with the same version of mutt
with a RedHat 5.2 (somewhat updated, but no core packackes, I think)
- this also seems to show, that the server does it job correctly.

- RedHat 6.1 with minor updates (but also tried it with a plain install), I
think I also already tested it with 6.2 (with same symptom), but I am not
sure anymore, so if this important, say so and I will try again. Also, if
you need more infos about versions / packages - maybe because they are not
as obvious as I think - please just say what I should provide.
- the NFS server has knfsd-1.2.2-4 installed and is based on RedHat 6.1, I
- mutt is 1.0.1i-6 installed from RedHat 6.2 (but also tested with earlier
version... upgraded to check whether the problem was already fixed)

Comment 1 Bill Nottingham 2000-05-16 16:09:59 UTC
You need to have the nfslock service started
on both the client and the server for NFS locking
to work correctly.

Comment 2 benjamin-redhat 2000-06-04 11:47:15 UTC
Sorry to come back to you so late, but I partially had to wait for feedback from
my administrator. By the way, I think the resolution "NOTABUG" is not correct,
because nfslock was not only not started, but also not installed at all,
although I have several NFS mounted devices.

The problem that I have now is that the server does not run a knfsd, but a user
space one (because it had stability problems which the user space one solved,
AFAIK), and nfslock seem to only be thought for knfsd.

Well, the server administrator refuses to switch back to knfsd. But I guess, it
must be possible somehow to "connect" also with a 6.1 system, when a 5.2 system
has no problem at all. If I am not wrong, the "solution" of the 5.2. system was
that locking did not really lock the stuff. Am I correct? If so, I would be
happy with a similar solution for 6.1, because there will be no concurrent
accesses. Do you have any suggestions for me? Thank you for your attention.

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