Same problem here. However, mine is on the client side.
On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
When I mount my NFS server 192.168.120.254, it works. However, if I want
to use some tool which need to lock file to save the file on the NFS
server, e.g.

vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
I get the message "lockd: cannot monitor 192.168.120.254", and the
message shown on the /var/log/daemon.log:
May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
of 192.168.120.254
May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
192.168.120.254


I have to put a lookup setting in /etc/hosts, something like
192.168.120.254 nfs-server
then the command vgcfgbackup can successfully save the file on the NFS dir.
This bug is really annoying especially in the private IP addresses
environment. It's really a pain to put all the possible machines on the
/etc/hosts.
Please consider this as a serious issue, because it will cause a lot of
NFS-based computing clusters fail.

My 2 cents.

Steven.

--
Steven Shiau<steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 1024D/9762755A
Fingerprint: A2A1 08B7 C22C 3D06 34DB F4BC 08B3 E3D7 9762 755A




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BF71C27.7070309@nchc.org.tw">http://lists.debian.org/4BF71C27.7070309@nchc.org.tw

On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote:
> Same problem here. However, mine is on the client side.
> On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
> When I mount my NFS server 192.168.120.254, it works. However, if I want
> to use some tool which need to lock file to save the file on the NFS
> server, e.g.
> vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
> I get the message "lockd: cannot monitor 192.168.120.254", and the
> message shown on the /var/log/daemon.log:
> May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
> of 192.168.120.254
> May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
> 192.168.120.254
[...]

nfs-utils 1.2.2 includes the change:

commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Jan 14 12:24:15 2010 -0500

statd: Support IPv6 in sm_mon_1_svc()

This appears to have removed support for IPv4 literals. Was this
intentional?

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

On 05/21/10 09:38 PM, Ben Hutchings wrote:

On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote:

Same problem here. However, mine is on the client side.
On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
When I mount my NFS server 192.168.120.254, it works. However, if I want
to use some tool which need to lock file to save the file on the NFS
server, e.g.
vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
I get the message "lockd: cannot monitor 192.168.120.254", and the
message shown on the /var/log/daemon.log:
May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
of 192.168.120.254
May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
192.168.120.254

[...]

nfs-utils 1.2.2 includes the change:

commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
Author: Chuck Lever<chuck.lever@oracle.com>
Date: Thu Jan 14 12:24:15 2010 -0500

statd: Support IPv6 in sm_mon_1_svc()

This appears to have removed support for IPv4 literals. Was this
intentional?


statd usually requires a DNS reverse mapping for any host it monitors.
Does your DNS have a reverse mapping for 192.168.120.254?


It looks like the new logic is more restrictive than the old statd when
mon_name is a presentation address. The old code simply allowed
presentation addresses with no reverse mapping. The new code requires a
reverse DNS mapping for presentation addresses. I think even an entry
in /etc/hosts would allow a raw address to work in this case.


We can probably remove the reverse mapping constraint for presentation
addresses. A simple fix might be to change statd_canonical_name() from:


freeaddrinfo(ai);
if (!result)
return NULL;

to

freeaddrinfo(ai);
if (!result)
return strdup(hostname);

Let me know if this works.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4BFA99CD.2040902@oracle.com">http://lists.debian.org/4BFA99CD.2040902@oracle.com

On 05/24/10 11:22 AM, Chuck Lever wrote:

On 05/21/10 09:38 PM, Ben Hutchings wrote:

On Sat, 2010-05-22 at 07:49 +0800, Steven Shiau wrote:

Same problem here. However, mine is on the client side.
On sid system, running kernel is 2.6.32-5-686, nfs-common is 1:1.2.2-1.
When I mount my NFS server 192.168.120.254, it works. However, if I want
to use some tool which need to lock file to save the file on the NFS
server, e.g.
vgcfgbackup -f $NFS_MNT_POINT/vg.cfg
I get the message "lockd: cannot monitor 192.168.120.254", and the
message shown on the /var/log/daemon.log:
May 21 08:52:44 debian rpc.statd[1298]: STAT_FAIL to debian for SM_MON
of 192.168.120.254
May 21 08:52:44 debian rpc.statd[1298]: No canonical hostname found for
192.168.120.254

[...]

nfs-utils 1.2.2 includes the change:

commit 8ce130c4c828b9d13d429f22160f992b9c1d45cd
Author: Chuck Lever<chuck.lever@oracle.com>
Date: Thu Jan 14 12:24:15 2010 -0500

statd: Support IPv6 in sm_mon_1_svc()

This appears to have removed support for IPv4 literals. Was this
intentional?


statd usually requires a DNS reverse mapping for any host it monitors.
Does your DNS have a reverse mapping for 192.168.120.254?

It looks like the new logic is more restrictive than the old statd when
mon_name is a presentation address. The old code simply allowed
presentation addresses with no reverse mapping. The new code requires a
reverse DNS mapping for presentation addresses. I think even an entry in
/etc/hosts would allow a raw address to work in this case.

We can probably remove the reverse mapping constraint for presentation
addresses. A simple fix might be to change statd_canonical_name() from:

freeaddrinfo(ai);
if (!result)
return NULL;

to

freeaddrinfo(ai);
if (!result)
return strdup(hostname);

Let me know if this works.


Any update? I have a patch ready for nfs-utils to fix this regression,
but I need confirmation that it addresses your problem.




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C0819C2.2020203@oracle.com">http://lists.debian.org/4C0819C2.2020203@oracle.com

On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
> On 05/24/10 11:22 AM, Chuck Lever wrote:
[...]
> > We can probably remove the reverse mapping constraint for presentation
> > addresses. A simple fix might be to change statd_canonical_name() from:
> >
> > freeaddrinfo(ai);
> > if (!result)
> > return NULL;
> >
> > to
> >
> > freeaddrinfo(ai);
> > if (!result)
> > return strdup(hostname);
> >
> > Let me know if this works.
>
> Any update? I have a patch ready for nfs-utils to fix this regression,
> but I need confirmation that it addresses your problem.

Steven originally had this problem, not me. Steven, do you need me to
build a new package with this change?

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

On 2010年06月06日 04:29, Ben Hutchings wrote:

On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:


On 05/24/10 11:22 AM, Chuck Lever wrote:


[...]


We can probably remove the reverse mapping constraint for presentation
addresses. A simple fix might be to change statd_canonical_name() from:

freeaddrinfo(ai);
if (!result)
return NULL;

to

freeaddrinfo(ai);
if (!result)
return strdup(hostname);

Let me know if this works.


Any update? I have a patch ready for nfs-utils to fix this regression,
but I need confirmation that it addresses your problem.


Steven originally had this problem, not me. Steven, do you need me to
build a new package with this change?

Ben.



Ben,
Yes, please.
Thanks.

Steven.

--
Steven Shiau<steven _at_ nchc org tw> <steven _at_ stevenshiau org>
National Center for High-performance Computing, Taiwan.
http://www.nchc.org.tw
Public Key Server PGP Key ID: 1024D/9762755A
Fingerprint: A2A1 08B7 C22C 3D06 34DB F4BC 08B3 E3D7 9762 755A




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C0FA7FD.3000301@nchc.org.tw">http://lists.debian.org/4C0FA7FD.3000301@nchc.org.tw

On 06/ 9/10 10:41 AM, Steven Shiau wrote:



On 2010年06月06日 04:29, Ben Hutchings wrote:

On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:

On 05/24/10 11:22 AM, Chuck Lever wrote:

[...]

We can probably remove the reverse mapping constraint for presentation
addresses. A simple fix might be to change statd_canonical_name() from:

freeaddrinfo(ai);
if (!result)
return NULL;

to

freeaddrinfo(ai);
if (!result)
return strdup(hostname);

Let me know if this works.

Any update? I have a patch ready for nfs-utils to fix this regression,
but I need confirmation that it addresses your problem.

Steven originally had this problem, not me. Steven, do you need me to
build a new package with this change?

Ben.


Ben,
Yes, please.
Thanks.


Any progress on this?



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4C33624D.2070405@oracle.com">http://lists.debian.org/4C33624D.2070405@oracle.com

On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote:
> On 06/ 9/10 10:41 AM, Steven Shiau wrote:
> >
> >
> > On 2010年06月06日 04:29, Ben Hutchings wrote:
> >> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
> >>> On 05/24/10 11:22 AM, Chuck Lever wrote:
> >> [...]
> >>>> We can probably remove the reverse mapping constraint for presentation
> >>>> addresses. A simple fix might be to change statd_canonical_name() from:
> >>>>
> >>>> freeaddrinfo(ai);
> >>>> if (!result)
> >>>> return NULL;
> >>>>
> >>>> to
> >>>>
> >>>> freeaddrinfo(ai);
> >>>> if (!result)
> >>>> return strdup(hostname);
> >>>>
> >>>> Let me know if this works.
> >>> Any update? I have a patch ready for nfs-utils to fix this regression,
> >>> but I need confirmation that it addresses your problem.
> >> Steven originally had this problem, not me. Steven, do you need me to
> >> build a new package with this change?
> >>
> >> Ben.
> >>
> > Ben,
> > Yes, please.
> > Thanks.
>
> Any progress on this?

I've heard nothing from Steven but one positive report from another
user. In any case we'll include this in our package.

We now have a git repository of the nfs-utils package at
<git://git.debian.org/kernel/nfs-utils.git>; currently our changes are
kept in a quilt patch series in debian/patches.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

On Aug 8, 2010, at 12:59 AM, Ben Hutchings wrote:

> On Tue, 2010-07-06 at 13:05 -0400, Chuck Lever wrote:
>> On 06/ 9/10 10:41 AM, Steven Shiau wrote:
>>>
>>>
>>> On 2010年06月06日 04:29, Ben Hutchings wrote:
>>>> On Thu, 2010-06-03 at 17:08 -0400, Chuck Lever wrote:
>>>>> On 05/24/10 11:22 AM, Chuck Lever wrote:
>>>> [...]
>>>>>> We can probably remove the reverse mapping constraint for presentation
>>>>>> addresses. A simple fix might be to change statd_canonical_name() from:
>>>>>>
>>>>>> freeaddrinfo(ai);
>>>>>> if (!result)
>>>>>> return NULL;
>>>>>>
>>>>>> to
>>>>>>
>>>>>> freeaddrinfo(ai);
>>>>>> if (!result)
>>>>>> return strdup(hostname);
>>>>>>
>>>>>> Let me know if this works.
>>>>> Any update? I have a patch ready for nfs-utils to fix this regression,
>>>>> but I need confirmation that it addresses your problem.
>>>> Steven originally had this problem, not me. Steven, do you need me to
>>>> build a new package with this change?
>>>>
>>>> Ben.
>>>>
>>> Ben,
>>> Yes, please.
>>> Thanks.
>>
>> Any progress on this?
>
> I've heard nothing from Steven but one positive report from another
> user. In any case we'll include this in our package.
>
> We now have a git repository of the nfs-utils package at
> <git://git.debian.org/kernel/nfs-utils.git>; currently our changes are
> kept in a quilt patch series in debian/patches.

Thanks, I'll submit the latest version of this to the nfs-utils maintainer.

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






--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 6C244072-B1DA-4F2D-8707-767DBAAC13B5@oracle.com">http://lists.debian.org/6C244072-B1DA-4F2D-8707-767DBAAC13B5@oracle.com