lkml.org 
[lkml]   [1999]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: smbfs still timing out
Date
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/libdl.so.2...done.
> Reading symbols from /lib/libcrypt.so.1...done.
> Reading symbols from /lib/libpam.so.0...done.
> Reading symbols from /lib/libc.so.6...done.
> Reading symbols from /lib/ld-linux.so.2...done.
> Reading symbols from /lib/libnss_files.so.1...done.
> Reading symbols from /lib/libnss_nis.so.1...done.
> Reading symbols from /lib/libnsl.so.1...done.
> Reading symbols from /lib/libnss_dns.so.1...done.
> Reading symbols from /lib/libresolv.so.2...done.
> 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
> http://www.unt.edu/bcis
> Visit my Website at http://people.unt.edu/~mev0003
> *****************************************************************
> For 93 million miles, there is nothing between the sun and my shadow
> except me. I'm always getting in the way of something...

Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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