Messages in this thread | | | From | "Michael H. Warfield" <> | Subject | Re: smbfs still timing out | Date | Mon, 29 Mar 1999 09:14:17 -0500 (EST) |
| |
Matthew Vanecek enscribed thusly: > On 29 Mar, brent verner spewed forth: > :: ima dummy. my source wasn't even at 2.0.3... > :: i was working in a 2.0.2 tree (that i've been > :: dabbling in...) disregard previous message. > :: > :: brent
> 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/
| |