From: NeilBrown <neilb@suse.de>
To: tasleson@redhat.com
Cc: linux-nfs@vger.kernel.org, Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH] exportfs: Return non-zero exit value on error
Date: Thu, 24 Oct 2013 09:18:11 +1100 [thread overview]
Message-ID: <20131024091811.34b06e71@notabene.brown> (raw)
In-Reply-To: <52680917.4010509@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2348 bytes --]
On Wed, 23 Oct 2013 12:36:23 -0500 Tony Asleson <tasleson@redhat.com> wrote:
> On 10/22/2013 08:44 PM, NeilBrown wrote:
> > On Tue, 22 Oct 2013 10:23:14 -0500 Tony Asleson <tasleson@redhat.com> wrote:
> >> The reason I chose to return values was to make sure requested operation
> >> actually completed requested operation. Unexporting a non-existent
> >> export is not considered an error and returns no indication you did
> >> absolutely nothing.
> >
> > Hi,
> > thanks makes sense - I had missed that (even though you explained it in the
> > patch description :-( )
> >
> > With your patch, if asked to unexport something that wasn't exported it
> > would not report any error, but would exit with an error status. Is that
> > correct? I think I would rather have a message printed if there is an error.
>
> Correct, I only made changes for the exit status. I was trying to make
> changes that would be mostly invisible to end users. I have no concerns
> adding a printed error output too, but others may.
>
> Changing the behavior of any command line tool is potentially
> problematic when scripted.
>
> > So would something like this (on top of my patch) address you need, or was
> > there something else I missed?
>
> Yes, this should work for the unexport fs case.
>
> However, the reason my patch was a little more invasive was to ensure
> that both the export and unexport paths were covered.
>
> For example, if the strdup call fails in function client_init, we fail
> the operation and return exit value of 0. Unlikely, but just the first
> example I stumbled across.
I think it is a lot closer to "impossible" than just "unlikely".
malloc doesn't fail in this sort of context, the OOM killer kills something
off instead.
My personal preference is to replace all malloc/calloc/strdup calls with
the xmalloc, xstrdup etc calls in support/nfs/xcommon.c.
If you are worried about malloc failing, I'd much prefer to see a patch which
changes nfs-utils to use those uniformly.
There might be a question over the best behaviour for daemons like mountd
and gssd. However as we move towards having systemd manage those, they will
be restarted if they ever exit, and they are mostly stateless so that is
quite safe.
Does anyone else have thoughts on this?
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-10-23 22:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 23:29 [PATCH] exportfs: Return non-zero exit value on error Tony Asleson
2013-10-21 22:25 ` NeilBrown
2013-10-22 8:38 ` Steve Dickson
2013-10-22 15:23 ` Tony Asleson
2013-10-23 1:44 ` NeilBrown
2013-10-23 17:36 ` Tony Asleson
2013-10-23 22:18 ` NeilBrown [this message]
2013-10-23 23:31 ` Chuck Lever
2013-10-24 15:56 ` Steve Dickson
2013-10-24 16:05 ` Chuck Lever
2013-10-28 3:39 ` NeilBrown
2013-10-28 14:09 ` Chuck Lever
2013-10-24 5:34 ` Tony Asleson
2013-10-22 8:30 ` Steve Dickson
2013-10-22 8:36 ` Steve Dickson
2013-10-28 22:35 ` NeilBrown
2013-11-04 15:33 ` 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=20131024091811.34b06e71@notabene.brown \
--to=neilb@suse.de \
--cc=SteveD@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tasleson@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).