linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Mi Jinlong <mijinlong@cn.fujitsu.com>
Cc: Steve Dickson <SteveD@redhat.com>, NFS <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] svc: make sure mountd can get ports from /etc/services
Date: Thu, 21 Apr 2011 10:11:11 -0400	[thread overview]
Message-ID: <5A8AD10C-81A4-4088-BCFA-08D0BA2337C7@oracle.com> (raw)
In-Reply-To: <4DAFA7AB.9020507@cn.fujitsu.com>


On Apr 20, 2011, at 11:42 PM, Mi Jinlong wrote:

> 
> 
> Chuck Lever:
>> On Apr 20, 2011, at 5:29 AM, Mi Jinlong wrote:
>> 
>>> 
>>> Chuck Lever:
>>>> Hi MJ-
>>>> 
>>>> On Apr 19, 2011, at 4:33 AM, Mi Jinlong wrote:
>>>> 
>>>>> At RHEL, if user set port for mountd at /etc/services as 
>>>>> "mount   12345/tcp", mountd should be bind to 12345, but the 
>>>>> latest nfs-utils, mountd get a rand port, not 12345.
>>>>> 
>>>>> This patch make sure mountd be bind to the port which was set
>>>>> at /etc/service.
>>>> I don't think this is documented anywhere.  Is there a reason it should work this way?
>>>> 
>>>> The typical way to set mountd's port is to use a command line option.  That's the way it works for all the other RPC daemons.  By default the ports are set up at random and registered with rpcbind.  That's why clients use rpcbind, and not /etc/services, to find these services.
>>> I don't have a depth research, agree with you.
>>> But I got different result when I set port for mountd at /etc/services
>>> between nfs-utils-1.2.3 and nfs-utils-1.2.2.
>> 
>> IMO that's unintentional behavior.  Could I ask a favor: would you bisect nfs-utils to find out exactly where this started and ended?
> 
>  Hi Chuck,
> 
>  It's after your patch "mountd: Support TI-RPC mountd listener" 
>  (commit id:b551b1fd0052de9b8c674b30c39d9f2a1e9d79cc).
> 
>  Before this patch, mountd call rpc_init to create rpc socket,
>  after it, if HAVE_LIBTIRPC is defined, mountd will call 
>  nfs_svc_create to create rpc socket, that appears.

Thanks.  I don't immediately see how that code path consults /etc/services.  There are no calls to getservby{name,port}(3) in either mountd or in libtirpc.  Did I miss something?  Any idea?

You said it stopped working after a while.  Can you bisect that as well?

Note that if nfs-utils is built without TI-RPC support, rpc_init() is still used instead of nfs_svc_create().  If nfs_svc_create() is indeed the proximal cause of this behavior, mountd won't consult /etc/services if it is built without TI-RPC support.  So it might be a bug if this works for some build configurations and doesn't work for others.  The question is should it always work, or should it never work; see below.

> 
>> 
>>> I just think we should get the same result at new nfs-utils as older.
>> 
>> Is there a real-world use case for this feature?  Why isn't the command line option adequate?
>> 
> 
>  I have a test site which depend on this feature.
>  If this feature indeed unnecessary, I will try to modify my test site.

Without knowing more about your test site, I claim it can and should use the "-p" option on rpc.mountd.  If your distribution of choice is Red Hat-based, you can set this in /etc/sysconfig/nfs (see MOUNTD_PORT=).

In other words, we have a documented and supported mechanism now, that should always work, for setting mountd's listener port.  Can you explain in detail why allowing /etc/services to have this effect is also necessary?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com





  reply	other threads:[~2011-04-21 14:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19  8:33 [PATCH] svc: make sure mountd can get ports from /etc/services Mi Jinlong
2011-04-19 13:28 ` Chuck Lever
2011-04-20  9:29   ` Mi Jinlong
2011-04-20 15:08     ` Chuck Lever
2011-04-21  3:42       ` Mi Jinlong
2011-04-21 14:11         ` Chuck Lever [this message]
2011-04-25  7:09           ` Mi Jinlong
2011-04-25 15:58             ` Chuck Lever
2011-05-28  9:42 ` [PATCH v2] rpc.mountd: let mountd consult /etc/services for port Mi Jinlong
2011-05-28 13:29   ` Jim Rees
2011-05-28 16:01     ` Chuck Lever
2011-05-28 16:45       ` Jim Rees
2011-06-07 20:17         ` Steve Dickson
2011-06-10  8:23           ` Mi Jinlong
2011-08-03 17:52   ` 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=5A8AD10C-81A4-4088-BCFA-08D0BA2337C7@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=SteveD@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mijinlong@cn.fujitsu.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).