On Tue, 27 Nov 2012 08:58:41 -0500 "Matthew M. DeLoera" <mdeloera@xxxxxxxxx> wrote: > I'm testing in an older kernel - 2.6.15-55-386. While mount sits and waits, I see cifsoplockd and cifsnotifyd, but no cifsd. And no /proc/PID/stack for either. When I kill mount -a, both of those cifs daemons remain running (both sleeping). > > I then tried later 2.6.24-24-generic kernel and got same behavior. > > Either way, for the record, cifsnotifyd was already running. Once I started mount, then cifsoplockd started. > > Now in an even newer kernel, 2.6.32-15.generic, I get much quicker timeout - just over 30 seconds. > > I still have to work with the older kernels I mentioned, though I'm glad to see the behavior in 32-15. And FYI, I never saw cifsd running in 32-15. > > Agreed about kill -9. It seems like cifs timeout behavior must have changed along the way, but my kernels span about 6 years, so that doesn't surprise me. But since I am still stuck with the older kernels I mentioned, is there something better that I could do, or just settle for kill -9 and allow enough time for newer kernels to timeout? Is there a way that I might be able to detect what timeout value I might expect? > > Cheers, > - Matthew > > Strange...cifsd is the demultiplex thread that handles the receive path. It usually also handles connecting the socket, but I don't recall if that was always the case as far back as 2.6.15... In any case, I think your choices boil down to backporting patches to lower the timeouts, or somehow working around the problem in userspace. If you know that the thing won't be mountable at boot time, you can always set it up as a "noauto" mount and simply mount it by hand when you know the connection is there. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
