Bug 88982 - RHL 9 NFS-Server Bug
RHL 9 NFS-Server Bug
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
9
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-15 19:08 EDT by Stephen Argo
Modified: 2014-01-21 17:48 EST (History)
5 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Stephen Argo 2003-04-15 19:08:22 EDT
Description of problem:
Using XMMS, on a RHL 7.3 box, I load a directory of audio files on a RHL 9 box,
thru it's nfs-server.  The problem I'm having is: audio files are being cut off
prematurely while playing and XMMS is going on to the next file in my playlist.
   I did not have this problem with RHL 8.0's version of nfs-server.  More
importantly, installing RHL 9 on a different box over NFS, from a RHL 9
nfs-server, using ISO's and a floppy bootdisk, failed several times due to "file
not found"; meaning the RHL 9 nfs-server cut off the floppy installer's
nfs-client, several times.  I was able to complete the new RHL 9 NFS
installation after 3 attempts, however.  The burned ISO's had no problem
installing, and had no "file not found" errors during installation.

Version-Release number of selected component (if applicable):
nfs-utils-1.0.1-2.9

How reproducible:
Problem recurs fairly easily.  The best method would be to try installing
another distro, over NFS, from a RHL 9 nfs-server.

Steps to Reproduce:
1. Set up an nfs-server on a RHL 9 box.
2. Try playing audio files continuously over NFS, from a client box.
3. Also, try installing a full distro on a different box, using ISO's stored on
the RHL 9 nfs-server, and see how far you get before "file not found" comes up.
    
Actual results:
NFS Server on my RHL 9 box seems to cut off client connections prematurely.

Expected results:
NFS Server should operate as it did in RHL 8.0 (should not reset NFS client
connections).

Additional info:
My RHL 9 nfs-server was setup using the "NFS Server" GUI tool found in System
Settings>Server Settings submenu, with "sync,rw" as the only options, and
"192.168.1.100/20" as my allowable hosts.
Comment 1 ldd 2003-04-24 14:42:13 EDT
I have experienced similar problems that are consistent with the NFS server on
RH 9 being buggy.  I spent most of the day yesterday trying to do an NFS install
of RH 9 (from a server already running RH 9), each NFS install failed at random
points during the package installation.  Sometimes anaconda would complain that
a package was missing, sometimes it would terminate with signal 11.  I checked
the media and it was fine.  The hardware I was using is also usually stable. 
After following many dead-end hypotheses (I probably tried a dozen NFS
installs), I tried an FTP installation and it worked on the first try.

Note that I did an NFS install of RH 9 using an RH 8 NFS server earlier with the
same CD and much of the same hardware and that worked fine.

Someone at RH might want to mark bug #89050 as a duplicate of this or
vice-versa, by the way.
Comment 2 Martijn Feleus 2003-07-24 08:00:29 EDT
I, too, experience problems with the RH9 nfs server. When trying to write from a
client on an nfs-mounted directory, the client will hang and after some time
spawn the "nfs server not responding" error message. Read-only shares work ok,
since I installed 2 machines via a RH9-based nfs server without a hitch. I set
everything up identically to my workplace environment which runs flawlessly on
100+ RH8 computers (which I admin). It seems that kernel versions don't matter
at all, since I tried this with kernels 2.4.18-14, 2.4.20-8, 2.4.20-18.9,
2.4.20-19.9 and 2.4.20-20.1.2013.nptl (on the server) with no difference in
behaviour. 

I can state with some certainty that the nfs-utils package is the source of the
problem. The RH9 version(s) 1.0.1-2.9 and 1.0.1-3.9 and the rawhide version
1.0.3-4.1 all exhibit this problem, while the RH8 version (1.0.1-2) does not.

This of course is an acceptable workaround, but things still smell fishy and
need fixing...
Comment 3 Martijn Feleus 2003-07-24 15:05:35 EDT
Whoa, spank me for talking too early! It now seems that nfs service provided by
nfs-utils 1.0.1-2 is just as unusable as the others, but for a different (set
of) reason: the initial success was achived by not using some normally running
services on that particular machine as I was regressing back to a former 'known
good' state.

My guess is now the following: on a (relatively) pristine desktop-type RH9
install the nfs runs normally from what I can see. Differences between the
working nfs server and the disfunctional one are these services: the latter also
runs dhcpd, iptables, squid, smb, ups, postfix, yppasswdd and ypserv. When I
tested this machine with success, the client wasn't using its services at all
(these came from my working server instead). Could it be that one of these
services interferes with nfs?

FWIW, I reverted all software to initial RH9 versions on this non-functioning
nfs server.
Comment 4 David Kohrn 2004-01-16 14:38:09 EST
I am in the process of porting a multi-cpu application from a single 
IRIX supercomputer to several dual-Xeon boxes.  I had planned to 
share the executables and data files over NFS, so I wouldn't need a 
copy on each node.  The NFS "file not found" errors that happen 
frequently would seem to make that an untenable solution if my users 
are going to have a usable system when I'm done.

I am running multiple hyperthreaded dual-Xeon machines, using the SMP 
kernel.  I have changed the clock granularity in my kernel (HZ in the 
make file) to 960 to allow better real-time scheduling.



I believe that the severity of this bug should be changed to "high", 
as NFS is an essential part of most non-trivial UNIX programming 
environments.  I can't even build my applications reliably, since my 
code base is NFS-mounted from my configuration management server.
Comment 5 Steve Dickson 2004-01-16 17:36:07 EST
Would it be possbile to post an ethereal trace (i.e. ethereal -w
/tmp/data) of this issue?
Comment 6 Steve Dickson 2004-08-11 07:38:17 EDT
I have not seen anything like this lately so I'm going
to close this as fixed in currentl release.

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