Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!news.unit0.net!news.mixmin.net!aioe.org!bofh.it!news.nic.it!robomod From: Sergio Gelato Newsgroups: linux.debian.bugs.dist,linux.debian.kernel Subject: Bug#895404: NFS server stops accepting mount request / mounted NFS directories became inaccessible on client Date: Thu, 12 Apr 2018 21:10:02 +0200 Message-ID: References: X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Thu Apr 12 19:06:09 2018 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -3.96 Reply-To: Sergio Gelato , 895404@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: Debian kernel team X-Debian-Pr-Message: followup 895404 X-Debian-Pr-Package: nfs-kernel-server X-Debian-Pr-Source: nfs-utils X-Spam-Bayes: score:0.0000 Tokens: new, 24; hammy, 150; neutral, 115; spammy, 0. spammytokens: hammytokens:0.000-+--H*u:NeoMutt, 0.000-+--H*UA:NeoMutt, 0.000-+--nfsd, 0.000-+--nfscommon, 0.000-+--nfs-common MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, outbound-su-se:default, su-se:default, base:default, @@RPTN) X-Canit-Geo: ip=130.237.181.83; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6 X-Canitpro-Stream: outbound-su-se:outbound (inherits from outbound-su-se:default,su-se:default,base:default) X-Canit-Stats-ID: 0aVxuUW8s - a9c9795c53f4 - 20180412 X-Canit-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) X-Greylist: delayed 347 seconds by postgrey-1.36 at buxtehude; Thu, 12 Apr 2018 19:02:54 UTC X-Debian-Message: from BTS X-Mailing-List: archive/latest/1453921 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 42 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Thu, 12 Apr 2018 20:56:57 +0200 X-Original-Message-ID: <20180412185657.3hfdjcizqvbaxslv@hanuman.astro.su.se> X-Original-References: <152343369321.10927.17259409877474737737.reportbug@nfs-backup-egisez> Xref: csiph.com linux.debian.bugs.dist:892326 linux.debian.kernel:60677 control: severity -1 normal control: tags -1 + moreinfo Dear reporter, I'm sorry to hear that you have lost data. However, it doesn't seem very constructive to make a bug release-critical without providing enough detail to make a fix possible. NFS is a complex network protocol, and the root cause of unexpected behaviour isn't always obvious at first glance. First of all, has this bug been filed against the right package? The nfsd processes are actually kernel threads (that's one reason "kill -9" doesn't work on them), the corresponding package is the kernel image. How many clients are accessing that NFS server when the problem occurs? I see that you have RPCNFSDCOUNT=8 but the address range for allowed clients is a /27. If you have 30 clients all trying to write at the same time, some of them are going to have to wait until a server thread becomes available. "server not responding, still trying" is a common symptom of this. Have you tried tuning the server? You can adjust the thread count without a reboot. I don't see sec=krb5p in your /etc/exports, so NFS traffic on the wire is probably unencrypted. Have you looked at it with tcpdump or a similar tool, particularly when the problem occurs? For example it would be nice to know whether that "Connection timed out" you get from mount.nfs is for the portmapper (unlikely), for mountd, or for nfsd itself. (strace may also tell you some of this.) Are you familiar with rpcdebug? If client traffic is coming in but the server isn't replying, you could set debugging flags and look at kernel log output. Other available debugging tools include the kernel's event tracing subsystem, as well as nfsstat, nfsiostat and mountstats from package nfs-common. (The last two are client-side, so maybe not so useful if your problem really is at the server end.) I can't help you much more than this: my own environment is NFSv4-only (and I feel no urge to look back) while yours is anything but. But if you manage to pinpoint more precisely what's wrong, someone else may be able to provide better hints (or you may figure it out yourself).