Bug 164263 - nfs locks fails causing a hang
Summary: nfs locks fails causing a hang
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 4
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-26 13:32 UTC by Samuel Irlapati
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-02 09:45:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
data saved from ethereal (7.42 MB, application/octet-stream)
2005-07-27 19:10 UTC, Samuel Irlapati
no flags Details

Description Samuel Irlapati 2005-07-26 13:32:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
I think there is a problem with locks. I have tried re-installing several times and still keep coming up with the same problem.
My home disk is mounted from an HP-UX machine using nfs. When i most programs, probably programs that use gconf, the program does not start, it just hangs. Looking in the /var/log/messages, i see the error "Jul 25 15:02:32 ustr-irlapasj-1 kernel: lockd: server 192.63.251.150 not responding, still trying"
Please help, for now my account seems useless. I use this at work.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.7-8, 

How reproducible:
Always

Steps to Reproduce:
1.Start gedit in an account where the home disk is nfs mounted.
2.
3.
  

Actual Results:  Gedit never starts

Expected Results:  gedit should have started

Additional info:

Comment 1 Steve Dickson 2005-07-27 12:23:04 UTC
Would it be possible to get a bzip2 network trace of this problem?
Something similar to 'ethereal -w /tmp/data.pcap ; bzip2 /tmp/data.pcap'

Comment 2 Samuel Irlapati 2005-07-27 19:10:28 UTC
Created attachment 117207 [details]
data saved from ethereal

I got this output by opening the ethereal gui, watching on eth0, waiting till i
got the message "Jul 27 12:58:54 ustr-irlapasj-1 kernel: lockd: server
192.63.251.150 not responding, still trying" in /var/log/messages, then saving
the data and exiting out off the program. I had to do it this way since
ethereal for me brings up a gui. 

If you need any other output, do not hesitate to ask.

Comment 3 Steve Dickson 2005-07-28 14:14:54 UTC
The ethereal trace show exactly what's being logged that
the client is sending the lock request, and re-sending  the
request (about 4 or 5 times) until (I assuming) the application
quits or somebody type ctrl-C....

So the next step is to see why the server is ignoring the
lock request. Is there anything errors being logged on
the server? 

Comment 4 Samuel Irlapati 2005-07-28 14:44:39 UTC
Nothing gets logged in the server. It is an HP-UX machine.
$(uname -a)=HP-UX trj5000d B.11.11 U 9000/785 2004190631 unlimited-user license
That is the server.

Do you need anything else?

Comment 5 Steve Dickson 2005-07-28 19:32:36 UTC
Yeah... way to reproduce this... ;-) Unfortunately we don't have that
type of server inhouse....

I wounder if it has something to do with how the filesystems
are exported.... Does HP have an 'exportfs -v' equivalent? 

Comment 6 Samuel Irlapati 2005-07-28 19:54:00 UTC
This worked with FC3, i started to get this problem only with FC4. Also nothing
changed on the server end. They do not have an exportfs command. They do have an
export command.

Comment 7 Samuel Irlapati 2005-07-29 18:18:30 UTC
I moved my home account from being on a HP-UX machine to a Linux machine, and
the problem i had with nfs locks disappeared. Thak you for your help. I decided
to move my home disk space so that i could get you more info on the nfs locks
problem, instead of having to rely on HP-UX. Looks like it worked out for the best.

Comment 8 Steve Dickson 2005-08-02 09:45:40 UTC
Well thats good to hear... so I'm going to close out this bz report....



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