[lkml]   [1999]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: smbfs still timing out
Matthew Vanecek enscribed thusly:


> Here is the output from gdb:

> root:reliant me2v$ gdb /usr/bin/smbmount
> GNU gdb 4.17
> Copyright 1998 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (gdb) attach 16508
> Attaching to program `/usr/bin/smbmount', process 16508
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> Reading symbols from /lib/
> 0x400a4237 in pause ()
> (gdb) continue
> Continuing.

> (gdb) continue
> Continuing.

> Program received signal SIGUSR1, User defined signal 1.
> 0x400a4237 in pause ()
> (gdb) where
> #0 0x400a4237 in pause ()
> #1 0x804aad0 in send_fs_socket ()
> #2 0x804adec in cmd_mount ()
> #3 0x804b2d1 in process ()
> #4 0x804c06e in main ()
> (gdb)

Ok... So far so good... That is a normal reconnect sequence and
that "SIGUSR1" is the smbmount daemon waking up to reconnect after a
connection failure. Tell it to continue at this point and the connection
should be re-established and back to normal. Maybe this is a deeper problem
that is occuring after a couple of reconnects? I'm interested in the case
where the connection fails and you DON'T get a SIGUSR1 (you'll have to tell
it to continue after each SIGUSR1 to keep going).

If it is a deeper reconnect problem, this gives me a hint on how
I might reproduce it. I'll have to tinker with one of my NT boxes to
get it to periodically drop connections and see if I can kill that daemon.

> I'll try it again with the password on the command line and see what
> happens.

You'll probably get the same results. At this point, the evidence
is pointing in a different direction.

This is getting curiouser and curiouser... /;-/

> --
> Matthew Vanecek
> Studies in Business Computers at the University of North Texas
> Visit my Website at
> *****************************************************************
> For 93 million miles, there is nothing between the sun and my shadow
> except me. I'm always getting in the way of something...

Michael H. Warfield | (770) 985-6132 |
(The Mad Wizard) | (770) 925-8248 |
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.031 / U:83.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site