Bug 8424 - NFS server, not responding..
NFS server, not responding..
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: nfs-utils (Show other bugs)
7.0
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-12 18:12 EST by luke
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-24 22:22:35 EST
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 luke 2000-01-12 18:12:20 EST
I have three redhat systems one is an NFS server and two is an NFS clients,
they are:
server:
Redhat 6.0
Kernel: 2.2.13 SMP
knfsd: 1.4.7-7

client1:
Redat 6.0
kernel: 2.2.12-20smp
knfsd: 1.4.7-7
knfsd clients: 1.4.7-7

client2:
Redhat 6.0
kernel: 2.2.13
knfsd: 1.4.7-7
knfsd clients: 1.4.7-7

The client system is typicually losing the server system.
When this happens, it is not for a long time period, maybe serveral seconds
but it is causing pauses on the client side as people are trying to access
files.  These pauses are very frustrating to the users.  This is happening
abour 30 times a day as well.

Here are log messages from the systems:
server:
Jan 12 14:21:40 khan kernel: fh_verify: sweets/.nfs0003d803000000e9
permission failure, acc=2, error=13
Jan 12 14:59:02 khan kernel: fh_verify: a/admin permission failure, acc=1,
error=13
Jan 12 14:59:49 khan kernel: fh_verify: a/admin permission failure, acc=1,
error=13
Jan 12 14:59:49 khan kernel: fh_verify: a/admin permission failure, acc=1,
error=13
Jan 12 15:01:38 khan kernel: fh_verify: d/daver permission failure, acc=1,
error=13
nfsd_d_validate: invalid address feebbaca
nfsd_d_validate: invalid address feebbaca
get_empty_dquot: pruning 465

client1:
Jan 11 14:13:21 spock kernel: nfs: task 23473 can't get a request slot
Jan 12 14:01:08 spock kernel: nfs: server khan2 OK
Jan 12 14:02:03 spock kernel: nfs: server khan2 not responding, still
trying
Jan 12 14:02:03 spock kernel: nfs: server khan2 OK
Jan 12 14:09:39 spock kernel: nfs: server khan2 not responding, still
trying
Jan 12 14:09:39 spock kernel: nfs: server khan2 not responding, still
trying
Jan 12 14:09:50 spock kernel: nfs: task 37169 can't get a request slot
Jan 12 14:09:58 spock kernel: nfs: server khan2 OK
Jan 12 14:21:42 spock kernel: NFS: can't silly-delete
sweets/.nfs0003d803000000e
9, error=-13

client2:
Jan 12 15:07:41 locutus kernel: nfs: task 34523 can't get a request slot
Jan 12 15:07:42 locutus kernel: nfs: task 34524 can't get a request slot
Jan 12 15:14:12 locutus kernel: nfs: server khan2 not responding, still
trying
Jan 12 15:14:15 locutus kernel: nfs: server khan2 OK
Jan 12 15:14:15 locutus kernel: nfs: server khan2 OK
Jan 12 15:15:33 locutus kernel: nfs: server khan2 not responding, still
trying
Jan 12 15:15:34 locutus kernel: nfs: server khan2 not responding, still
trying
Jan 12 15:15:39 locutus kernel: nfs: server khan2 OK
Jan 12 15:15:39 locutus kernel: nfs: server khan2 OK

Let me know if there is any more information I can provide to aid the
solving of this problem.

Thanks,

Luke
Comment 1 Cristian Gafton 2000-01-13 12:20:59 EST
there is some heavy networking going on there that makes the kernel on the
client side to run out of available sockets. I doubt this is related to the NFS
server.

Adjusted priorities and severity of the problem report.
Comment 2 luke 2000-03-01 16:25:59 EST
Do you know where I would look to see about adjusting the number of sockets on
the client system?
Comment 3 Cristian Gafton 2000-08-08 22:36:26 EDT
assigned to johnsonm
Comment 4 frenzel 2001-02-27 17:13:48 EST
We have 3 Dell Precision 420 workstations, 2 with single CPUs 
(the clients/desktops), one with two CPUs (intended as 
compute/file/print/web server). Each workstation exports file systems via NFS 
to the other two. Accessing the NFS mounted file systems on the server from 
the clients often results in hangups ("NFS task xxx can't get a request slot") 
of the clients for a few seconds up to several minutes. 
This must be a problem with the SMP kernel - if I run the single-processor 
kernel (RH 2.2.16-22 in both cases) on the server, 
the problem does not exist. There is also no problem in accessing the file 
systems on the clients from the server. Network traffic is always low, ping 
gives times around 150 useconds even during an NFS hangup. The load on the 
server is also very low.
Comment 5 Stephen John Smoogen 2003-01-24 22:22:35 EST
The running out of slots and other problems listed above were mainly fixed with
the newer nfsd that showed up in Red Hat Linux 7.2. The configuration of the
server can be found in man rpc.nfsd command to get the number of threads to
start and should be configured in /etc/rc.d/inet.d/nfs

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