From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: mounting a SCO nfs export to a FC3 machine hangs when you try to read a large file (appears to be aroud 64k or larger). Most of the time 2 or 3 minutes passes and the file will appear,sometimes it never does. This just started happening at the same time i had to start putting the nfsvers=2 option in /etc/fstab. It seems the more you use it, the less likely it is to hang. Version-Release number of selected component (if applicable): kernel-2.6.10-1.741_FC3 How reproducible: Sometimes Steps to Reproduce: 1.vim/cat a file over 64k 2. 3. Actual Results: terminal hangs, <CTRL C> wont kill it Expected Results: file should have opened/ displayed Additional info: NFS export is on a SCO Open Server 5.0.7 (but will do the same thing on Open Server 5.0.4)
would it be possible to post a b2zip ethetreal trace of the hang?
Created attachment 110617 [details] tethereal log
Not that familiar with ethereal. This is a tethereal log for about 45seconds of the hang. 192.9.23.74 is the SCO server, 192.9.23.12 is my FC3 machine. Hope this helps.
Created attachment 110622 [details] Begining to end hang Here is a log from the start to the finish of a hang, about 2 mins. I greped the SCO server IP address.
hmm... there definitely appears to be a large number of retransmission.... To get a better look would you mind creating a binary capture file by using the -w flag to tethereal similar to: tethereal -w /tmp/trace.pcap host server and host client I should have been more explicit in my original request... my bad... :) Also would it be possible to post the netstat -c stats from the client side and the netstat -s from the server side.... Finally, when the process hangs on the client, could you get a system wide trace by "echo t > /proc/sysrq-trigger", then posting the relevant parts from /var/log/messages....
Created attachment 110647 [details] tethereal -w hang
Created attachment 110648 [details] /var/log/messages This is all that came out in /var/log/messages
Created attachment 110650 [details] netstat -c
Created attachment 110652 [details] netstat -s
Thanks for the info.... So is it valid to say this hang only happen on the v2 filesystems and not on v3 mounted filesystems.
Yes, other nfs mounts that are exported from newer linux boxes do not suffer from this problem. Everyone in the company that uses FC suffers from this with our sco machines. I also saw a usenet post that someone else was having the same problem with SCO exports.(dont know if I can find it again). I cant say if its a SCO specific problem or not I'm a little suspicious though. Older RedHat Linux versions dont seem to have this problem, nor do our Enterprise servers that mount from SCO. Bart
There seems to be a number of nfs mount bugs like this that need info about the server and if it provides NFS via udp, tcp, both. For me the older servers do not provide tcp and mount and autofs both appear to hang. Apparently there is a problem checking for services and the 'wrong' type of connection is tried and hangs. For me the critical info is 'rpcinfo'..... $ rpcinfo -p troubleserver | grep nfs 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs $ rpcinfo -p happyserver | grep nfs 100003 4 tcp 2049 nfs Older Linux and older appliance software wuold be involved. 100003 3 tcp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 udp 2049 nfs 100003 2 udp 2049 nfs Our current work arround is to specify tcp/udp to match the server in the mount line and mount maps. In my case the server is not SCO but an older RH release.. (Kernel... 2.4.20-28.8bigmem) (the other bugzillas that might match what I see are 140631, 144556, 144758)
Could you please try the util-linux in http://people.redhat.com/steved/bz152956 It fixes a problem that appears to be simlar to this one...
It does help here..... I installed the new rpm in a safe place so I could compare and contrast.... testing with old code: $ rpm -q --file `which mount` util-linux-2.12a-21 # mount bxtop:/export/files /tmp/MMM mount to NFS server 'bxtop' failed: server is down. # yep my problem... Now with mount from the new rpm as per steved above... I installed it in /tmp/MMMroot and testing it looks good.... [root@box tmp]# /tmp/MMMroot/bin/mount bxtop:/export/files /tmp/MMM [root@box tmp]# <--- Most excelent silence is golden [root@box tmp]# [root@box tmp]# df # Now check... Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda3 22928148 10042224 11721212 47% / none 513108 0 513108 0% /dev/shm bxtop:/export/files 222029360 90235928 131793432 41% /tmp/MMM # and Yes it mounted... So yes this does help my observed problem.
*** This bug has been marked as a duplicate of 152956 ***
Thank you for your feedback!
didnt fix our sco problem.
You said: "This just started happening at the same time i had to start putting the nfsvers=2 option in /etc/fstab. It seems the more you use it, the less likely it is to hang." and I'm sure I understand what you mean. Are you saying that using v2 causes the hang or does not cause the hang?
We used rh 9 for a while then upgraded our workstations to FC3 and we couldnt mount anything via nfs. Then we figured out we had to add nfsvers=2 to /etc/fstab in order to get our machines to mount the exported nfs directory. I guess what i was saying in a round about way was that it was not broken in previous releases of RedHat and I figured that there was a big update to the nfs stuff that caused it to break because I now had to specify the nfs version in addition to the hang. I have backed my workstation up to RHEL3WS and the nfs works flawlessly. We do still have a couple of FC3 machines in place if you need any output from one of them. I will be spending the rest of the day upgrading my machine to RHEL4WS. I'll let you know if its in there too. Bart
I have the same problem - Can't mount an SCO - OpenServer(TM) Release 5 (scosysv 3.2 5.0.5 i386)) export (exported with "/ -access=access=bu-fs-n:rmt-fs,root=bu-fs-n:rmt-fs"). If the /etc/fstab line does NOT contains "nfsver=2", I get the message: mount to NFS server 'bu-sdr' failed: server is down. When it DOES contain "nfsver=2" the system crashes.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
Works OK in kernel 2.6.17-1.2145_FC5. Previous kernels (2.6.15) had problems when trying to mount more than 1 NFS disk.