[...]
> 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/