From: NeilBrown <neilb@suse.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 1/2] mount.nfs: trust the exit status of "start_statd".
Date: Thu, 17 Dec 2015 15:27:34 +1100 [thread overview]
Message-ID: <20151217042734.7581.35502.stgit@noble> (raw)
In-Reply-To: <20151217042613.7581.1566.stgit@noble>
If DNS service is particularly slow, nfs_probe_statd() can fail even
though rpc.statd is actually running. This happens because rpc.statd
is single threaded and could be waiting longer for DNS than
nfs_probe_statd() will wait for it.
This causes problems when mount.nfs uses nfs_probe_statd() to see if
statd is running, as is needed for NFSv3.
Currently in these circumstances there are two possible outcomes.
1/ if systemd is in use, it will be told to start rpc-statd, which
is already running so no change.
mount.nfs will try pinging rpc.statd a few more times and could
eventually give up and fail the mount.
While slow DNS may well result in slow service, it shouldn't cause
a mount attempt to fail.
2/ if systemd is not in use, a new rpc.statd will be started. This
can (and has) lead to a large number of rpc.statd processes running
on the one machine.
This patch addresses the first scenario. If START_STATD is run and
exits with a success status, mount.nfs assumes statd is running and
allows the mount to succeed. A separate patch will address the other
scenario.
Signed-off-by: NeilBrown <neilb@suse.com>
---
utils/mount/network.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/utils/mount/network.c b/utils/mount/network.c
index 8a9bf1476d51..7240ca7bcdc4 100644
--- a/utils/mount/network.c
+++ b/utils/mount/network.c
@@ -794,6 +794,7 @@ int start_statd(void)
if (stat(START_STATD, &stb) == 0) {
if (S_ISREG(stb.st_mode) && (stb.st_mode & S_IXUSR)) {
int cnt = STATD_TIMEOUT * 10;
+ int status = 0;
const struct timespec ts = {
.tv_sec = 0,
.tv_nsec = 100000000,
@@ -808,7 +809,10 @@ int start_statd(void)
progname, strerror(errno));
break;
default: /* parent */
- waitpid(pid, NULL,0);
+ if (waitpid(pid, &status,0) == pid &&
+ status == 0)
+ /* assume it worked */
+ return 1;
break;
}
while (1) {
next prev parent reply other threads:[~2015-12-17 4:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-17 4:27 [PATCH nfs-utils 0/2] Fix problems caused by rpc.statd being unresponsive NeilBrown
2015-12-17 4:27 ` NeilBrown [this message]
2015-12-17 4:27 ` [PATCH 2/2] start-statd: don't run multiple rpc.statds on the one host NeilBrown
2016-01-16 21:58 ` [PATCH nfs-utils 0/2] Fix problems caused by rpc.statd being unresponsive Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151217042734.7581.35502.stgit@noble \
--to=neilb@suse.com \
--cc=SteveD@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.