[lkml]   [1999]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: smbfs still timing out
    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/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > Reading symbols from /lib/
    > 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
    > Visit my Website at
    > *****************************************************************
    > For 93 million miles, there is nothing between the sun and my shadow
    > except me. I'm always getting in the way of something...

    Michael H. Warfield | (770) 985-6132 |
    (The Mad Wizard) | (770) 925-8248 |
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:51    [W:0.025 / U:0.060 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site