cmdebug produced not output and returned within 2 secs.
Not dynroot.
ls -ld /afs did not hang
ls -ld /afs/our.org hung here:
dtrace: script 'traceafs.d' matched 2594 probes
CPU FUNCTION
0 -> afs_root
0 <- afs_root
0 -> gafs_lookup
0 -> afs_lookup
0 -> afs_InitFakeStat
0 <- afs_InitFakeStat
0 -> afs_InitReq
0 -> PagInCred
0 <- PagInCred
0 <- afs_InitReq
0 -> afs_EvalFakeStat
0 -> afs_EvalFakeStat_int
0 <- afs_EvalFakeStat_int
0 <- afs_EvalFakeStat
0 -> afs_AccessOK
0 -> afs_GetAccessBits
0 <- afs_GetAccessBits
0 <- afs_AccessOK
0 -> Check_AtSys
0 <- Check_AtSys
0 -> osi_dnlc_lookup
0 <- osi_dnlc_lookup
0 -> afs_GetDCache
0 -> afs_MemGetDSlot
0 -> Afs_Lock_ReleaseR
0 -> afs_osi_Wakeup
0 -> afs_getevent
0 <- afs_getevent
0 <- afs_osi_Wakeup
0 <- Afs_Lock_ReleaseR
0 <- afs_MemGetDSlot
0 -> afs_osi_Sleep
0 -> afs_getevent
0 <- afs_getevent
--
Jeff Blaine | G06A/ATCC/RCF
On 5/18/2011 11:39 AM, Derrick Brashear wrote:
On Wed, May 18, 2011 at 11:25 AM, Andrew Deason<[email protected]> wrote:
On Wed, 18 May 2011 11:11:37 -0400
Jeff Blaine<[email protected]> wrote:
Does 'cmdebug<client>' return anything?
Nope.
As in, it hangs, or it exits without any output?
But okay, to see where in libafs you're hanging, you can
dtrace -s traceafs.d -c "ls -ld /afs"
(as root) and give the output, or at least around the spot where it
hangs. I'm assuming 'ls -ld /afs' hangs, though. Just put some other
command in there otherwise.
actually, a relevant question in that vein, is this machine dynroot,
and what is the uppermost path component that hangs?
but you should still run the dtrace command regardless.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info