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):
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.
NFS Server on my RHL 9 box seems to cut off client connections prematurely.
NFS Server should operate as it did in RHL 8.0 (should not reset NFS client
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.
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.
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
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
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
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
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.
Would it be possbile to post an ethereal trace (i.e. ethereal -w
/tmp/data) of this issue?
I have not seen anything like this lately so I'm going
to close this as fixed in currentl release.