All of lore.kernel.org
 help / color / mirror / Atom feed
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) {



  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.