[gentoo-user] Re: [NOTE] New default behavior in latest nfs-utils (1.3.2-r1)

[walt]

On 02/01/2015 03:32 PM, wabenbau@×××××.com wrote:
> Am Sonntag, 01.02.2015 um 14:41
> schrieb walt <w41ter@×××××.com>:
>
>> On 02/01/2015 01:18 PM, walt wrote:
>>> I was happy with nfs3 until it stopped working for reasons I still
>>> don't understand :(
>>
>> Well, nfs3 still works, but only after failing on the first attempt:
>>
>> #mount.nfs a6://usr/portage /usr/portage -o nfsvers=3  hangs
>> indefinitely until I hit Ctrl-C.  If I then repeat the same command
>> immediately the mount succeeds.  This is the mysterious nfs black
>> magic I've run into many times over the years and makes me dread nfs
>> updates.
>
> Here is the postinstall info from the update to nfs-utils-1.3.1-r1.
> Maybe you run into that.
>
> "If you use OpenRC, the nfsmount service has been replaced with
> nfsclient. If you were using nfsmount, please add nfsclient and
> netmount to the same runlevel as nfsmount."

Thanks wabe.  I forgot to mention that I use systemd now, and I've
had to work out a few problems with nfs over past months because our
gentoo systemd scripts are lagging a bit behind upstream, which is
not surprising.

For example, I had to add the rpcbind.service to the multi-user
systemd target because even nfs3 seems to need it. (I knew when I
switched to systemd I was volunteering for some extra problems, but
I don't regret it.  Yet ;)

As I said in my earlier post, I've now disabled nfs4 in both kernel
and nfs-utils on all my machines, with the same result:  the first
attempt to mount an nfs3 share hangs indefinitely, but if I kill the
mount process and repeat it immediately, the mount succeeds.

I'd love to know if anyone else can reproduce this problem with nfs3
on either OpenRC or systemd.

Thanks!