rpc.lockd brokenness (2)

[Miguel Lopes Santos Ramos]

> Can you try to narrow down this problem some more?  e.g. look up the
> port used by rpc.lockd with rpcinfo on client and server and tcpdump
> to see what locking requests are being passed back and forth (you
> should see the request from client -> server and the reply granting
> the lock; or not if something is going wrong).  The ethereal port is
> useful for parsing the tcpdump -w -s 0 traces, btw; it decodes the RPC
> packets into human-readable form.

In the meanwhile, since my last mail, I've had some trouble finding out
the port that's used using rpcinfo. Using rpcinfo made me remember a few
things about rpc (I used it only once, some 6 years ago). I've found out
the right udp port by eliminating other options.

I will try to narrow the circumstances of this, if only to file a pr about it.
But tomorrow... It's almost 4am here, and almost 11pm there...

If you can in the meanwhile send me a message explaining how to find out
the right udp port quickly, it will set me up faster tomorrow.

> Running rpc.lockd -d100 on the server is also useful for tracking down
> what it's doing (look in /var/log/debug.log)

Yes, that will be easier.

> > If I keep using a common home directory for all machines, and keep using
> > lockd for that mount on that machine, then my only workaround is still to
> > go back to 6.0-RELEASE.
>
> I'm not certain 6.0-RELEASE is any different, since I don't see any
> changes to rpc.lockd or nfs locking that were made since then.

Yes, I had also checked that earlier today. I don't know if I did something
that could have caused this... I'm almost sure it worked on 6.0 (although not
completely, because I only got this machine working with 6 recently, it had
a problem with ehci). There's no doubt it was working with 5-something.

Miguel