7:06 p.m.
Upgrade to 2.6.3 fixed the issue. rpc.statd works with only IPv4 localhost
address.
On Tue, Sep 18, 2018 at 2:57 PM David C <dcsysengineer(a)gmail.com> wrote:
Naresh,
Did you get a solution to this in the end?
I'm having the same issue, just using the vfs FSAL
Ganesha 2.6.1
/var/log/messages filled with:
Sep 18 21:51:33 fsrv01 rpc.statd[2545]: SM_MON/SM_UNMON call from
non-local host ::1
Sep 18 21:51:33 fsrv01 rpc.statd[2545]: STAT_FAIL to pclhhfsrv01 for
SM_MON of ::ffff:10.10.10.220
Ganesha log filled with:
18/09/2018 21:51:33 : epoch 5ba09ee4 : fsrv01 :
ganesha.nfsd-23030[svc_206] nsm_monitor :NLM :CRIT :Monitor
::ffff:10.10.10.220 SM_MON failed (1)
I -can- ping ::ffff:10.10.10.220
I did try running with some clients accessing home directories but
eventually I got:
17/09/2018 15:06:27 : epoch 5b9fb130 : fsrv01 : ganesha.nfsd-4072[svc_24]
nsm_monitor :NLM :CRIT :Monitor ::ffff:10.10.10.240 SM_MON failed: RPC:
Timed out
Then I just go a load of "vfs_lookup_path :FSAL :CRIT :Could not open
directory for path" until I restarted ganesha
Any assistance would be much appreciated
Thanks
David
On Wed, Sep 12, 2018 at 1:03 PM Daniel Gryniewicz <dang(a)redhat.com> wrote:
> This list has been deprecated. Please subscribe to the new devel list at
> lists.nfs-ganesha.org.
> Oh, it looks like rpc.statd is refusing the connection because it
> doesn't think ::1 (the IPv6 localhost address) is localhost. If so,
> this would be either a bug or a misconfiguration in rpc.statd.
>
> Daniel
>
> On 09/11/2018 11:31 PM, Naresh Babu wrote:
> > Thanks for the response, Daniel. Ping to "::ffff:10.0.0.7" works
fine.
> > Do you suspect anything else?
> >
> > Thanks,
> > Naresh
> >
> > On Tue, Sep 11, 2018 at 5:48 AM Daniel Gryniewicz <dang(a)redhat.com
> > <mailto:dang@redhat.com>> wrote:
> >
> > My guess is that this is related to IPv6. IPv6 support in 2.5 was
> > spotty, but that's been fixed since. It's clearly using the 4-in-6
> > address (pretty common on a v6 enabled machine), and I don't
> believe it
> > could have used that in 2.5, so that's seems the smoking gun.
> >
> > Does IPv6 work on your system? If you ping ::ffff:10.0.0.7 on that
> > box,
> > does it work? If the problem is IPv6, you may be able to work
> > around it
> > by preferring IPv4 to IPv6. This is done by adding this line to
> > /etc/gai.conf:
> >
> > precedence ::ffff:0:0/96 100
> >
> > Daniel
> >
> > On 09/11/2018 03:42 AM, Naresh Babu wrote:
> > > This list has been deprecated. Please subscribe to the new devel
> > list at lists.nfs-ganesha.org <http://lists.nfs-ganesha.org>;.
> > >
> > >
> > >
> > > We have developed a custom FSAL on top of nfs-ganesha 2.5.4
> > version and
> > > lock tests ran fine with that. But, after upgrading
> nfs-ganesha to
> > > 2.6.2, lock tests are failing with the following errors:
> > >
> > > ganesha.nfsd-1419[svc_70] nsm_monitor :NLM :CRIT :Monitor
> > > ::ffff:10.0.0.7 SM_MON failed (1)
> > >
> > > /var/log/messages:
> > > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: SM_MON/SM_UNMON call
> from
> > > non-local host ::1
> > > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: STAT_FAIL to mbclvm3 for
> > SM_MON
> > > of ::ffff:10.0.0.7
> > >
> > > $ rpcinfo -p |grep "status\|lockmgr"
> > > 100024 1 udp 46991 status
> > > 100024 1 tcp 33715 status
> > > 100021 4 udp 45075 nlockmgr
> > > 100021 4 tcp 45075 nlockmgr
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Nfs-ganesha-devel mailing list
> > > Nfs-ganesha-devel(a)lists.sourceforge.net
> > <mailto:Nfs-ganesha-devel@lists.sourceforge.net>
> > > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> > >
> >
>
>
>
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
>