[Samba] Samba Hang.

[Urban Widmark]

On Wed, 20 Mar 2002, Gavin Button wrote:

> <snip>
> > First try upgrading to the latest RH errata kernel. If that
> > doesn't work then try 2.4.17 (not .18) or 2.4.19-pre.
> 
> I updated to the latest version I could find on the redhat site, v2.4.9-31
> but the problem still exists. Should there be a newer version than this??

That is probably fine. You could try building a 2.4.19-pre from source.

> Is there anything else I should update? What package includes smbfs?

The kernel package.


The next step would otherwise be to try and find out where it hangs. This
can be a bit complicated ...

If you are using X you could try switching to the console and run the
hanging copy command from there. I have seen X hang while the consoles 
still work, sometimes with useful output.

smbfs can also be rebuilt with an option to be more verbose. If run from
the console then the last messages could give a hint. This requires 
compiling your own kernel.

There is also a kernel level debugger and various functions that can be
switched on to try and detect deadlocks. Again, requiring a kernel
compile.


Another thing to try is to use sysrq to see where various processes are 
when it hangs. If this will work depends a bit on how it hangs. You can 
enable sysrq with this command:
echo "1" > /proc/sys/kernel/sysrq

If you are using X, switch to the console and you should run the rest of
this from the console. If you now press SysRq (AltGr+PrintScreen) and H
you should get a help line showing various commands.

Create a directory /var/log/ksymoops owned by root.
(man insmod, see KSYMOOPS ASSISTANCE)

When this directory exists insmod will write some info here that can be
useful when decoding a stack trace into a kernel module (which smbfs is).

To ensure that the module info is written do like this:
 1. If smbfs is in use, umount all smbfs and rmmod the smbfs module (use 
    lsmod to see if the smbfs module is being used). Verify that it isn't 
    loaded.
 2. Run 'modprobe smbfs'
 3. Run 'sync' to get the module info on disk

SysRq+T lists all tasks with their name (the process that is copying is
interesting), including a dump of the kernel call-stack. These numbers
can then be used together with the info written by ksymoops to find out
which kernel functions that were called.

By copying these numbers for "interesting" tasks (copy to paper if nothing
else works) and then putting them in a file they can be decoded.

If syslog is still alive it should catch this output and log it to
/var/log/messages.

Example, one of my tcsh has this:
Call Trace: [<c01223e4>] [<c01701b3>] [<c016c061>] [<c016dcb2>] [<c013a596>] 

If I put that in a file and then run ksymoops on it I get this:
Trace; c01223e4 <schedule_timeout+14/a0>
Trace; c01701b3 <read_chan+393/740>
Trace; c016c061 <tty_read+e1/130>
Trace; c016dcb2 <tty_ioctl+372/390>
Trace; c013a596 <sys_read+96/110>

which says a lot about what that process was doing.

The ksymoops command looks like this, where "aa" is a file with the trace.
ksymoops -k /var/log/ksymoops/20020320202817.ksyms \
         -l /var/log/ksymoops/20020320202817.modules < aa
(on one line)

The numbered files are the files written by insmod, before triggering the
hang it may be useful to note what the most recently created file is
called.

/Urban