On Sun, 27 Aug 2006, Kostik Belousov wrote:
On server,
tcpdump -p -s 1500 -w file -i <iface> host <client host ip>
Ok. I've run
saturn# tcpdump -p -s 1500 -w tcpdump.out -i xl0 host 10.0.0.105
and run the failing test on venus (with `rpc.lockd -d1`). The failing
lockf has moved -- it took longer to fail this time -- but it does fail.
As before, one of the lockd processes has vanished.
venus# ps axlww | grep rpc\\.
0 18303 1 0 96 0 263460 916 select Ss ?? 0:00.00
/usr/sbin/rpc.statd -d
0 18308 1 0 96 0 1416 1024 select Is ?? 0:00.01
/usr/sbin/rpc.lockd -d1
1 18309 18308 0 4 0 1420 1036 nfsloc I ?? 0:00.00
/usr/sbin/rpc.lockd -d1
<run the test until it locks>
venus# ps axlww | grep rpc\\.
0 18303 1 0 96 0 263460 884 select Ss ?? 0:00.00
/usr/sbin/rpc.statd -d
1 18309 1 0 4 0 1440 1008 nfsloc S ?? 0:00.00
/usr/sbin/rpc.lockd -d1
Yes, this is very interesting. Does something appears in the logs ?
Also, you shall use -d option of rpc.lockd (and show the output together
with tcpdump output).
Well. See my previous message this smorning for -d output. As for
tcpdump, I have an interesting (and rather obvious) problem:
saturn# stat -f%z /tmp/tcpdump.out
161794058
Hmm. Perhaps you don't want that. I'll hang onto it for a bit: let me
know what you want to do with it!
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
