* Problem with rpcbind
@ 2012-10-05 15:09 VDR User
2012-10-08 10:58 ` Steve Dickson
0 siblings, 1 reply; 8+ messages in thread
From: VDR User @ 2012-10-05 15:09 UTC (permalink / raw)
To: linux-nfs
Per Aníbal Salazar, I'm sending this to the nfs mailing list..
==========
Hi. I would like to know who I can talk to about having the rpcbind's
timeout value settable on the command line by the user. In many cases
the timeout is too long, requiring hackish solutions. It would be
best, and makes sense, that the user should be able to set the timeout
to something other than the default value if he chooses. If you could
direct me to the right person to talk to about it, I'd appreciate it.
Cheers,
Derek
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-05 15:09 Problem with rpcbind VDR User
@ 2012-10-08 10:58 ` Steve Dickson
2012-10-08 16:47 ` VDR User
0 siblings, 1 reply; 8+ messages in thread
From: Steve Dickson @ 2012-10-08 10:58 UTC (permalink / raw)
To: VDR User; +Cc: linux-nfs
On 05/10/12 11:09, VDR User wrote:
> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>
> ==========
>
> Hi. I would like to know who I can talk to about having the rpcbind's
> timeout value settable on the command line by the user. In many cases
> the timeout is too long, requiring hackish solutions. It would be
> best, and makes sense, that the user should be able to set the timeout
> to something other than the default value if he chooses. If you could
> direct me to the right person to talk to about it, I'd appreciate it.
What timeout are you referring to? The one given to poll()?
steved.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-08 10:58 ` Steve Dickson
@ 2012-10-08 16:47 ` VDR User
2012-10-09 23:37 ` Steve Dickson
0 siblings, 1 reply; 8+ messages in thread
From: VDR User @ 2012-10-08 16:47 UTC (permalink / raw)
To: Steve Dickson; +Cc: linux-nfs
On Mon, Oct 8, 2012 at 3:58 AM, Steve Dickson <SteveD@redhat.com> wrote:
>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>
>> ==========
>>
>> Hi. I would like to know who I can talk to about having the rpcbind's
>> timeout value settable on the command line by the user. In many cases
>> the timeout is too long, requiring hackish solutions. It would be
>> best, and makes sense, that the user should be able to set the timeout
>> to something other than the default value if he chooses. If you could
>> direct me to the right person to talk to about it, I'd appreciate it.
>
> What timeout are you referring to? The one given to poll()?
Hi. I guess so but not really sure. I'm talking about the timeout that
happens when rpcbind is waiting for a response. Sounds like poll()
could be it. We have an nfs server on .100 and the response happens
immediately.
$ rpcinfo -t 192.168.1.100 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
program 100003 version 4 ready and waiting
but there's no server on say .101 so if we run the same command on
that ip, the timeout takes a very long time. It's this timeout that
should be user-definable on the command line in my opinion. Any
thoughts about it?
Cheers
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-08 16:47 ` VDR User
@ 2012-10-09 23:37 ` Steve Dickson
2012-10-10 2:49 ` VDR User
0 siblings, 1 reply; 8+ messages in thread
From: Steve Dickson @ 2012-10-09 23:37 UTC (permalink / raw)
To: VDR User; +Cc: linux-nfs
On 08/10/12 12:47, VDR User wrote:
> On Mon, Oct 8, 2012 at 3:58 AM, Steve Dickson <SteveD@redhat.com> wrote:
>>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>>
>>> ==========
>>>
>>> Hi. I would like to know who I can talk to about having the rpcbind's
>>> timeout value settable on the command line by the user. In many cases
>>> the timeout is too long, requiring hackish solutions. It would be
>>> best, and makes sense, that the user should be able to set the timeout
>>> to something other than the default value if he chooses. If you could
>>> direct me to the right person to talk to about it, I'd appreciate it.
>>
>> What timeout are you referring to? The one given to poll()?
>
> Hi. I guess so but not really sure. I'm talking about the timeout that
> happens when rpcbind is waiting for a response. Sounds like poll()
> could be it. We have an nfs server on .100 and the response happens
> immediately.
>
> $ rpcinfo -t 192.168.1.100 nfs
> program 100003 version 2 ready and waiting
> program 100003 version 3 ready and waiting
> program 100003 version 4 ready and waiting
>
> but there's no server on say .101 so if we run the same command on
> that ip, the timeout takes a very long time. It's this timeout that
> should be user-definable on the command line in my opinion. Any
> thoughts about it?
Hmm... I'm guess that is the 7min tcp connect time out cause by
the -t option... Try using -u instead of -t... Basically using
UDP instead of TCP... In general I would never recommend that
but in this particular case it might help...
steved.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-09 23:37 ` Steve Dickson
@ 2012-10-10 2:49 ` VDR User
2012-10-11 13:23 ` Steve Dickson
0 siblings, 1 reply; 8+ messages in thread
From: VDR User @ 2012-10-10 2:49 UTC (permalink / raw)
To: Steve Dickson; +Cc: linux-nfs
On Tue, Oct 9, 2012 at 4:37 PM, Steve Dickson <SteveD@redhat.com> wrote:
>>>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>>>
>>>> ==========
>>>>
>>>> Hi. I would like to know who I can talk to about having the rpcbind's
>>>> timeout value settable on the command line by the user. In many cases
>>>> the timeout is too long, requiring hackish solutions. It would be
>>>> best, and makes sense, that the user should be able to set the timeout
>>>> to something other than the default value if he chooses. If you could
>>>> direct me to the right person to talk to about it, I'd appreciate it.
>>>
>>> What timeout are you referring to? The one given to poll()?
>>
>> Hi. I guess so but not really sure. I'm talking about the timeout that
>> happens when rpcbind is waiting for a response. Sounds like poll()
>> could be it. We have an nfs server on .100 and the response happens
>> immediately.
>>
>> $ rpcinfo -t 192.168.1.100 nfs
>> program 100003 version 2 ready and waiting
>> program 100003 version 3 ready and waiting
>> program 100003 version 4 ready and waiting
>>
>> but there's no server on say .101 so if we run the same command on
>> that ip, the timeout takes a very long time. It's this timeout that
>> should be user-definable on the command line in my opinion. Any
>> thoughts about it?
>
> Hmm... I'm guess that is the 7min tcp connect time out cause by
> the -t option... Try using -u instead of -t... Basically using
> UDP instead of TCP... In general I would never recommend that
> but in this particular case it might help...
Thanks for this suggestion. I tried with -u but the timeout still
takes at least 1 min. Is it not feasible to have a command line
timeout where users can set it to something appropriate for their
needs? For example, in our case we only need about 5 seconds at most.
Cheers
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-10 2:49 ` VDR User
@ 2012-10-11 13:23 ` Steve Dickson
2012-10-11 15:02 ` VDR User
0 siblings, 1 reply; 8+ messages in thread
From: Steve Dickson @ 2012-10-11 13:23 UTC (permalink / raw)
To: VDR User; +Cc: linux-nfs
On 09/10/12 22:49, VDR User wrote:
> On Tue, Oct 9, 2012 at 4:37 PM, Steve Dickson <SteveD@redhat.com> wrote:
>>>>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>>>>
>>>>> ==========
>>>>>
>>>>> Hi. I would like to know who I can talk to about having the rpcbind's
>>>>> timeout value settable on the command line by the user. In many cases
>>>>> the timeout is too long, requiring hackish solutions. It would be
>>>>> best, and makes sense, that the user should be able to set the timeout
>>>>> to something other than the default value if he chooses. If you could
>>>>> direct me to the right person to talk to about it, I'd appreciate it.
>>>>
>>>> What timeout are you referring to? The one given to poll()?
>>>
>>> Hi. I guess so but not really sure. I'm talking about the timeout that
>>> happens when rpcbind is waiting for a response. Sounds like poll()
>>> could be it. We have an nfs server on .100 and the response happens
>>> immediately.
>>>
>>> $ rpcinfo -t 192.168.1.100 nfs
>>> program 100003 version 2 ready and waiting
>>> program 100003 version 3 ready and waiting
>>> program 100003 version 4 ready and waiting
>>>
>>> but there's no server on say .101 so if we run the same command on
>>> that ip, the timeout takes a very long time. It's this timeout that
>>> should be user-definable on the command line in my opinion. Any
>>> thoughts about it?
>>
>> Hmm... I'm guess that is the 7min tcp connect time out cause by
>> the -t option... Try using -u instead of -t... Basically using
>> UDP instead of TCP... In general I would never recommend that
>> but in this particular case it might help...
>
> Thanks for this suggestion. I tried with -u but the timeout still
> takes at least 1 min. Is it not feasible to have a command line
> timeout where users can set it to something appropriate for their
> needs? For example, in our case we only need about 5 seconds at most.
hmm... when I do a "rpcinfo -t <ip-address> nfs" to a machine that
does not have a daemon listening I immediately get:
rpcinfo: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) program 100003 is not available
So I not seeing here this hang is coming from...
steved.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: Problem with rpcbind
2012-10-11 13:23 ` Steve Dickson
@ 2012-10-11 15:02 ` VDR User
2012-10-15 20:28 ` Steve Dickson
0 siblings, 1 reply; 8+ messages in thread
From: VDR User @ 2012-10-11 15:02 UTC (permalink / raw)
To: Steve Dickson; +Cc: linux-nfs
On Thu, Oct 11, 2012 at 6:23 AM, Steve Dickson <SteveD@redhat.com> wrote:
>>>>>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>>>>>
>>>>>> ==========
>>>>>>
>>>>>> Hi. I would like to know who I can talk to about having the rpcbind's
>>>>>> timeout value settable on the command line by the user. In many cases
>>>>>> the timeout is too long, requiring hackish solutions. It would be
>>>>>> best, and makes sense, that the user should be able to set the timeout
>>>>>> to something other than the default value if he chooses. If you could
>>>>>> direct me to the right person to talk to about it, I'd appreciate it.
>>>>>
>>>>> What timeout are you referring to? The one given to poll()?
>>>>
>>>> Hi. I guess so but not really sure. I'm talking about the timeout that
>>>> happens when rpcbind is waiting for a response. Sounds like poll()
>>>> could be it. We have an nfs server on .100 and the response happens
>>>> immediately.
>>>>
>>>> $ rpcinfo -t 192.168.1.100 nfs
>>>> program 100003 version 2 ready and waiting
>>>> program 100003 version 3 ready and waiting
>>>> program 100003 version 4 ready and waiting
>>>>
>>>> but there's no server on say .101 so if we run the same command on
>>>> that ip, the timeout takes a very long time. It's this timeout that
>>>> should be user-definable on the command line in my opinion. Any
>>>> thoughts about it?
>>>
>>> Hmm... I'm guess that is the 7min tcp connect time out cause by
>>> the -t option... Try using -u instead of -t... Basically using
>>> UDP instead of TCP... In general I would never recommend that
>>> but in this particular case it might help...
>>
>> Thanks for this suggestion. I tried with -u but the timeout still
>> takes at least 1 min. Is it not feasible to have a command line
>> timeout where users can set it to something appropriate for their
>> needs? For example, in our case we only need about 5 seconds at most.
>
> hmm... when I do a "rpcinfo -t <ip-address> nfs" to a machine that
> does not have a daemon listening I immediately get:
> rpcinfo: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) program 100003 is not available
>
> So I not seeing here this hang is coming from...
The computers on our network run a mixture of different OS'es so maybe
that is relevant. Regardless though it makes sense that we should be
able to tell rpcbind to abort if I hasn't received a response within X
seconds. That's much better than being forced to wait predefined
timeouts, or timeouts in other places. Or is it just me?
Cheers
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Problem with rpcbind
2012-10-11 15:02 ` VDR User
@ 2012-10-15 20:28 ` Steve Dickson
0 siblings, 0 replies; 8+ messages in thread
From: Steve Dickson @ 2012-10-15 20:28 UTC (permalink / raw)
To: VDR User; +Cc: linux-nfs
On 11/10/12 11:02, VDR User wrote:
> On Thu, Oct 11, 2012 at 6:23 AM, Steve Dickson <SteveD@redhat.com> wrote:
>>>>>>> Per Aníbal Salazar, I'm sending this to the nfs mailing list..
>>>>>>>
>>>>>>> ==========
>>>>>>>
>>>>>>> Hi. I would like to know who I can talk to about having the rpcbind's
>>>>>>> timeout value settable on the command line by the user. In many cases
>>>>>>> the timeout is too long, requiring hackish solutions. It would be
>>>>>>> best, and makes sense, that the user should be able to set the timeout
>>>>>>> to something other than the default value if he chooses. If you could
>>>>>>> direct me to the right person to talk to about it, I'd appreciate it.
>>>>>>
>>>>>> What timeout are you referring to? The one given to poll()?
>>>>>
>>>>> Hi. I guess so but not really sure. I'm talking about the timeout that
>>>>> happens when rpcbind is waiting for a response. Sounds like poll()
>>>>> could be it. We have an nfs server on .100 and the response happens
>>>>> immediately.
>>>>>
>>>>> $ rpcinfo -t 192.168.1.100 nfs
>>>>> program 100003 version 2 ready and waiting
>>>>> program 100003 version 3 ready and waiting
>>>>> program 100003 version 4 ready and waiting
>>>>>
>>>>> but there's no server on say .101 so if we run the same command on
>>>>> that ip, the timeout takes a very long time. It's this timeout that
>>>>> should be user-definable on the command line in my opinion. Any
>>>>> thoughts about it?
>>>>
>>>> Hmm... I'm guess that is the 7min tcp connect time out cause by
>>>> the -t option... Try using -u instead of -t... Basically using
>>>> UDP instead of TCP... In general I would never recommend that
>>>> but in this particular case it might help...
>>>
>>> Thanks for this suggestion. I tried with -u but the timeout still
>>> takes at least 1 min. Is it not feasible to have a command line
>>> timeout where users can set it to something appropriate for their
>>> needs? For example, in our case we only need about 5 seconds at most.
>>
>> hmm... when I do a "rpcinfo -t <ip-address> nfs" to a machine that
>> does not have a daemon listening I immediately get:
>> rpcinfo: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused) program 100003 is not available
>>
>> So I not seeing here this hang is coming from...
>
> The computers on our network run a mixture of different OS'es so maybe
> that is relevant. Regardless though it makes sense that we should be
> able to tell rpcbind to abort if I hasn't received a response within X
> seconds. That's much better than being forced to wait predefined
> timeouts, or timeouts in other places. Or is it just me?
I guess... but there are a lot of timeout one has to deal with...
If its high on your priority, patches are always welcome... ;-)
steved.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-15 20:28 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-05 15:09 Problem with rpcbind VDR User
2012-10-08 10:58 ` Steve Dickson
2012-10-08 16:47 ` VDR User
2012-10-09 23:37 ` Steve Dickson
2012-10-10 2:49 ` VDR User
2012-10-11 13:23 ` Steve Dickson
2012-10-11 15:02 ` VDR User
2012-10-15 20:28 ` Steve Dickson
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).