Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: smbfs still timing out | Date | Sun, 28 Mar 1999 13:16:35 -0500 (EST) |
| |
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/
| |