> Ok, good, because according to gdb, both password and smb_login_passwd
> have the same values.
This is as it should be. That means the caching is probably working
correctly.
> What the general scheme of events seems to be is: connection gets
> dropped, smb_retry gets called by the kernel, and generates the
> smb_retry error message, with a -3 code, and smbmount exits.
Not quite... I think what is happening is: connection gets dropped,
smb_retry (which is in the kernel) signals smbmount, smbmount rebuilds
connection, connection gets dropped (at some time later), smb_retry
signals smbmount, smbmount rebuilds connection, (repeat n times), connection
gets dropped, smb_retry signals smbmount, smbmount may or may not rebuild
connection at this point but something fails and smbmount exits, smb_retry
signals smbmount and gets a -3 error because smbmount no longer exists.
The -3 error is because smbmount has already exited and the process
that smb_retry is trying to signal no longer appears to exist.
There is one path I know of for sure that will do this (because
I added it). If smbmount trys to rebuild the connection and fails (server
down, someone changed your password, whatever) smbmount attempts to unmount
the share and then exit. The idea is that the resource is no longer their
so why wait around. It is SUPPOSE to unmount the share and that SHOULD
clean up the smbfs module. That may not be working properly. This does
imply that you are encountering a fatal error during a reconnect attempt,
however.
I might try modifying that by introducing a sleep with a safety
counter so that if the connection attempt fails I would sleep for a few
seconds and then retry and only abort if the safety counter exceeded
some predefined limit (else you would hang forever). It would probably
help if I can descriminate between retryable errors (server down, network
down, etc) and permanent errors (invalid password on retry, bad resource,
etc).
Suggestion...
Edit smbmount.c in the samba package and uncomment the line for
SMBFS_DEBUG. Then rebuild smbmount and install. This will enable some
debugging information. When you run smbmount next, redirect stdout and
stderr to a couple of files (you will have to pass the password on the
command line or environment, since you won't see the password prompt).
Add a "-d 10" to the smbmount command to enable most of the debug prints.
Warning... Do not run a debugging version of smbmount with autofs!
It will cause autofs to hang because it fails to close its stdout and stderr
file descriptors, which is what automount is waiting for... (This is why
the debugging option is left disabled).
> I don't fully understand the code, and I'm not sure just exactly where
> the call to smb_retry comes from; from what I can see, it is internal
> to fs/smbfs/proc.c. If there were some documentation available
> detailing what is supposed to happen when a smb connection is dropped
> that I could look at? As in what code gets executed and when?
> Preferably starting from when the kernel/smbmount receives the signal
> that the connection is lost.
> --
> Matthew Vanecek
> Course of Study: http://www.unt.edu/bcis
> Visit my Website at http://people.unt.edu/~mev0003
> For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> *****************************************************************
> 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/