rpcbind -h
Subsystems (2)
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
And is there any good reason why an nfs3 client not providing any services would need to run rpcbind?
Quoted 5 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
And is there any good reason why an nfs3 client not providing any services would need to run rpcbind?
Yes: lockd and statd...
Trond
Signature · 6 lines
Trond Myklebust Linux NFS client maintainer NetApp [email protected] www.netapp.com
Trond Myklebust wrote:
Quoted 5 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
And is there any good reason why an nfs3 client not providing any services would need to run rpcbind?
Yes: lockd and statd...
Oh yeah, I forgot about those v3 relics. How about if all my mounts are nolock? And what about the '-h' option? It almost looks like a mistake, but it's documented to work that way.
Quoted 2 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
Yes. See the mail archives. I believe we've discussed this thoroughly within the past six months to a year. If there's any bug here, it's that "-h" is not well documented.
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
Chuck Lever wrote:
Quoted 2 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
Yes. See the mail archives. I believe we've discussed this thoroughly within the past six months to a year. If there's any bug here, it's that "-h" is not well documented.
It's documented well enough but I'm still in the dark about the reason. I don't recall the discussion and can't find it in the archives. The search box on spinics isn't working for me, it returns results from the entire web, not just the list archive.
As I said before, I was hoping for the equivalent of "portmap -l". I was ready to code up a patch of some kind but now have a workaround (mount with nolock and don't run rpcbind at all).
Quoted 11 lines · Jim Rees
Chuck Lever wrote:
Quoted 2 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
Yes. See the mail archives. I believe we've discussed this thoroughly within the past six months to a year. If there's any bug here, it's that "-h" is not well documented.
Quoted 8 lines
It's documented well enough but I'm still in the dark about the reason. I don't recall the discussion and can't find it in the archives. The search box on spinics isn't working for me, it returns results from the entire web, not just the list archive.
As I said before, I was hoping for the equivalent of "portmap -l". I was ready to code up a patch of some kind but now have a workaround (mount with nolock and don't run rpcbind at all).
I wouldn't object to having a "local only" option that turns off the AF_INET[6] listener and just listens on the AF_LOCAL socket, but that may be problematic until we have a complete transition away from glibc RPC, which still uses AF_INET loopback extensively.
Glad you found a work-around.
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com
On Mon, 7 Nov 2011 12:21:31 -0500, Jim Rees wrote:
rees> Chuck Lever wrote:
Quoted 2 lines · Jim Rees
Quoted 2 lines
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
rees> Yes. See the mail archives. I believe we've discussed this rees> thoroughly within the past six months to a year. If there's rees> any bug here, it's that "-h" is not well documented.
rees> It's documented well enough but I'm still in the dark about the rees> reason. I
Chuck's quote from the manpage reminded me - -h was used to work around the address selection: if server has more then one address the reply may use any of them. Some clients don't like it.
This issue should go away after
commit 74ef3df0236c55185225c62fba34953f2582da72
Author: Olaf Kirch <[email protected]> Date: Wed Mar 2 10:09:24 2011 -0500
was added to libtirpc.
rees> As I said before, I was hoping for the equivalent of "portmap rees> -l". I was ready to code up a patch of some kind but now have rees> a workaround (mount with nolock and don't run rpcbind at all).
iptables is another option.
max
Quoted 2 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
No... sounds like a bug to me...
steved.
Quoted 7 lines
And is there any good reason why an nfs3 client not providing any services would need to run rpcbind?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines · Steve Dickson
Quoted 2 lines · Jim Rees
Is there some good reason why the rpcbind '-h' option (bind to given address) applies only to the udp listening socket and not to the tcp socket?
No... sounds like a bug to me...
Behavior is described right in the man page. So this seems to be on purpose.
-h Specify specific IP addresses to bind to for UDP requests. This option
may be specified multiple times and is typically necessary when running on a multi-homed host. If no -h option is specified, rpcbind will bind to INADDR_ANY, which could lead to problems on a multi-homed host due to rpcbind returning a UDP packet from a different IP address than it was sent to. Note that when specifying IP addresses with -h, rpcbind will automatically add 127.0.0.1 and if IPv6 is enabled, ::1 to the list.
Signature · 2 lines
Chuck Lever chuck[dot]lever[at]oracle[dot]com