[OpenAFS] /afs area is hanging

Tue, 5 May 2009 10:41:34 -0600

This is a multipart message in MIME format.
--=_alternative 005BB052872575AD_=
Content-Type: text/plain; charset="US-ASCII"

Felix,

Thanks for the reply.  I am waiting for it to crash again to run the echo 
..... command below.

There also seems to be a separate issue with the LDAP server timing out. 
These messages show up in /var/log/messages.  It makes the afs area really 
slow but not totally hung.  I then restart nscd and the errors stop and 
all is well again.  This seems to be a seperate issue from the permanent 
afs hang taking place.

Mark Henry

Felix Frank <Felix.Frank@Desy.de> 
05/04/2009 11:46 PM

To
Mark Henry <mark.henry@infoprint.com>
cc
openafs-info@openafs.org
Subject
Re: [OpenAFS] /afs area is hanging

On Mon, 4 May 2009, Mark Henry wrote:

> I tried the -fakestat-all option and it did not work.

Weird.

> I have searched /var/log/messages.  I have checked the config files. 
User
> authentication works fine (even when the system is hanging).  If I run 
the
> command 'ls -l /afs' that window is hung (or any other command that
> references afs).  If an afs user logs in when the system is in a bad 
state
> the session immediately hangs because it can't cd to the afs home dir. I
> don't know what to do other than reboot.  Can someone tell me what else 
to
> try to find out why this system is hanging?  Thanks,

You can find out just which call gets stuck by issuing an
'echo t >>/proc/sysrq-trigger'. Call traces for all processes can then be
found in dmesg. The broken processes are probably in a D state.

This will probably not identify the root cause, but may give a clue about
what's going on.

HTH
  - Felix

_____________________________________________________________________________
"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." _____________________________________________________________________________
--=_alternative 005BB052872575AD_=
Content-Type: text/html; charset="US-ASCII"

Felix,
 
 Thanks for the reply. &nbsp;I am waiting
for it to crash again to run the echo ..... command below.
 
 There also seems to be a separate issue
with the LDAP server timing out. &nbsp;These messages show up in /var/log/messages.
&nbsp;It makes the afs area really slow but not totally hung. &nbsp;I then
restart nscd and the errors stop and all is well again. &nbsp;This seems
to be a seperate issue from the permanent afs hang taking place.
 
Mark Henry 

 
 
 
<table width=100%>
<tr valign=top>
<td width=40%>Felix Frank &lt;Felix.Frank@Desy.de&gt;

05/04/2009 11:46 PM
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right>To</div>
<td>Mark Henry &lt;mark.henry@infoprint.com&gt;
<tr valign=top>
<td>
<div align=right>cc</div>
<td>openafs-info@openafs.org
<tr valign=top>
<td>
<div align=right>Subject</div>
<td>Re: [OpenAFS] /afs area is hanging</table>
 
<table>
<tr valign=top>
<td>
<td></table>
 </table>
 
 
 <tt>On Mon, 4 May 2009, Mark Henry wrote: 
 
&gt; I tried the -fakestat-all option and it did not work. 
 
Weird. 
 
&gt; I have searched /var/log/messages. &nbsp;I have checked the config
files. &nbsp;User 
&gt; authentication works fine (even when the system is hanging). &nbsp;If
I run the 
&gt; command 'ls -l /afs' that window is hung (or any other command that 
&gt; references afs). &nbsp;If an afs user logs in when the system is in
a bad state 
&gt; the session immediately hangs because it can't cd to the afs home
dir. &nbsp;I 
&gt; don't know what to do other than reboot. &nbsp;Can someone tell me
what else to 
&gt; try to find out why this system is hanging? &nbsp;Thanks, 
 
You can find out just which call gets stuck by issuing an 
'echo t &gt;&gt;/proc/sysrq-trigger'. Call traces for all processes can
then be 
found in dmesg. The broken processes are probably in a D state. 
 
This will probably not identify the root cause, but may give a clue about 
what's going on. 
 
HTH 
 &nbsp;- Felix 
</tt>

_____________________________________________________________________________ 
"This message and any attachments are solely for the intended recipient and may contain confidential or privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." _____________________________________________________________________________

--=_alternative 005BB052872575AD_=--