On Monday, May 22, 2006 12:52:06 PM +0300 Juha Jäykkä <[EMAIL PROTECTED]> wrote:
- Output of 'cmdebug <client-ip-addr>'
Produced nothing at all. (Since this, and the next, line stated
"client-ip", I assumed they should be run on the server and the last on
the client. Hope I was correct! =) )
"nothing" is reasonable output from this command. Any output would have
described the state of currently-held locks within the cache manager; if
the problem had been some sort of deadlock, this would have help to
identify it.
It doesn't matter where you run cmdebug or rxdebug; they query the thing
you name on the command line and print some debugging data.
- Output of 'rxdebug <client-ip-addr> 7001'
Trying 130.232.104.188 (port 7001):
Free packets: 130, packet reclaims: 0, calls: 17469, used FDs: 64
not waiting for packets.
0 calls waiting for a thread
1 threads are idle
Done.
Also fairly normal
- Output of 'rxdebug <fileserver-ip-addr>'
lagrange:~# rxdebug dirac.tfy.utu.fi
Trying 130.232.105.174 (port 7000):
Free packets: 582, packet reclaims: 81, calls: 94967, used FDs: 64
not waiting for packets.
0 calls waiting for a thread
11 threads are idle
Connection from host 130.232.104.188, port 7001, Cuid 83aaa7c0/4dff9bc,
error 19270409 serial 6, natMTU 1444, flags pktCksum, security index 2,
server conn rxkad: level clear, flags pktCksum
Received 0 bytes in 0 packets
Sent 0 bytes in 0 packets
call 0: # 182, state precall, mode: error
You've seen Derrick's comment on this connection. The call is in state
precall mode error, with an error code that means the tickets are expired.
This was probably not the case when you were actually seeing a problem, so
it doesn't give us much. You should collect the same data again next time
you see the problem.
As Derrick mentions, you should use tcpdump -s 1500 -x, which will print
full dumps of the contents of each packet. A couple of more -v's wouldn't
hurt, either, though tcpdump's ability to decode AFS packets is a bit
limited.
Connection from host 130.232.105.162, port 7001, Cuid b06eb0e7/118cd340
serial 1074, natMTU 1444, security index 0, client conn
call 0: # 537, state dally, mode: receiving, flags: receive_done
call 1: # 0, state not initialized
call 2: # 0, state not initialized
call 3: # 0, state not initialized
This connection is irrelevant to this issue. I probably should have told
you to use the '-nodally' switch to rxdebug, which would have suppressed
this connection.
-- Jeff
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
