From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Steve Dickson <steved@redhat.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH nfs-utils] statd: Don't unregister statd service on failing to execute callout
Date: Mon, 15 Feb 2016 16:43:24 +0900 [thread overview]
Message-ID: <56C1819C.7040908@lab.ntt.co.jp> (raw)
In-Reply-To: <989760D9-029D-43E2-ABA3-8DC9F579BE68@oracle.com>
On 2016/02/13 0:40, Chuck Lever wrote:
> Hi-
Hi,
>> On Feb 12, 2016, at 1:41 AM, Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>>
>> statd calls atexit(statd_unregister) to unregister statd service on exit,
>> which actually has a side-effect that ha_callout() unregisters statd
>> service even when the child callout process exits on execl() failure.
>>
>> Certain clustering software's deployment script adds -H option with its
>> specified file non-existent, when it is configured not to use callout.
>> In other words, -H seems to be used no matter if callout is needed or not,
>> but when callout is unnecessary, the specified callout program is not
>> deployed.
>> This causes statd not to work once a lock is requested by its NFS client,
>> as execl() in ha_callout() results in ENOENT and exit() of the child
>> process calls exit-handler statd_unregister(). Eventually, the NFS client
>> gets stuck with messages "lockd: cannot monitor xxx" on the NFS server.
>>
>> Although this may not be an expected way of using -H option, it would be
>> better if statd could continue to work even in that situation. Also,
>> execl() could fail for other reasons like ENFILE and EIO, where statd
>> service should not be unregistered as well.
>> Call _exit(), which does not call any exit-handlers, instead of exit() to
>> take care of those situations and make statd more reliable.
>
> OK, but I think the explanation could be simpler? It doesn't
> seem like a matter of "it would be better if" but more like
> "a forked child must not unregister the statd RPC server."
> In other words, this seems like a real bug to me, not an
> enhancement.
Thank you for your feedback.
Here is a simpler one.
If it looks fine to you, I'll send v2 with your Reviewed-by.
---
-Although this may not be an expected way of using -H option, it would be
-better if statd could continue to work even in that situation. Also,
-execl() could fail for other reasons like ENFILE and EIO, where statd
-service should not be unregistered as well.
-Call _exit(), which does not call any exit-handlers, instead of exit() to
-take care of those situations and make statd more reliable.
+Also, execl() could fail for other reasons like ENFILE or EIO as well.
+
+A forked child must not unregister the statd RPC server, so use
+_exit(), which does not call any exit-handlers, instead of exit().
---
Regards,
Toshiaki Makita
next prev parent reply other threads:[~2016-02-15 7:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 6:41 [PATCH nfs-utils] statd: Don't unregister statd service on failing to execute callout Toshiaki Makita
2016-02-12 15:40 ` Chuck Lever
2016-02-15 7:43 ` Toshiaki Makita [this message]
2016-02-15 14:46 ` Chuck Lever
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=56C1819C.7040908@lab.ntt.co.jp \
--to=makita.toshiaki@lab.ntt.co.jp \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@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 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.