From: Steve Dickson <SteveD@redhat.com>
To: VDR User <user.vdr@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Problem with rpcbind
Date: Mon, 15 Oct 2012 16:28:41 -0400 [thread overview]
Message-ID: <507C71F9.6040201@RedHat.com> (raw)
In-Reply-To: <CAA7C2qjd-mtSjc79T4EkV1_vUbJpqOQ53PjPQoW-eC6U7uv1Vw@mail.gmail.com>
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.
prev parent reply other threads:[~2012-10-15 20:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
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 message]
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=507C71F9.6040201@RedHat.com \
--to=steved@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=user.vdr@gmail.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).