Jeff Moyer wrote:
> ==> Regarding Re: [autofs] automount never umount; Ian Kent <[EMAIL 
> PROTECTED]> adds:
> 
> raven> On Wed, 23 Nov 2005, Jeff Moyer wrote:
> 
>>>==> Regarding Re: [autofs] automount never umount; Farkas Levente
>>><[EMAIL PROTECTED]> adds:
>>>
> 
> lfarkas> Ian Kent wrote:
> 
>>>>>On Wed, 23 Nov 2005, Farkas Levente wrote: >>> Jeff Moyer wrote:
>>>
>>>output of dmesg or /var/log/daemon? there is nothing >>> in dmesg.  i'm
>>>running this kernel currently and mount nfs and smbfs >>> servers.
>>>
>>>>>>---------------------------
>>>>>>root 1974 0.0 0.0 1788 736 ?  Ss 10:05 0:00 /usr/sbin/automount >>>
>>>
>>>--timeout=60 --debug /smb program /etc/auto.smb root 1976 0.0 0.0 1788
>>>
>>>>>>736 ?  Ss 10:05 0:00 /usr/sbin/automount --timeout=60 --debug /net
>>>>>>program /etc/auto.net
>>>>>>---------------------------
>>>>>>how long should i wait? as the timeout is 1 minute, they should have
>>>
>>>to >>> be umounted, but not. here is the relevant part of daemon log
>>>which >>> don't tell me too much:-(
>>>
>>>>>
>>>>>You've waited long enough. Your timeout was 60 seconds.
>>>>>
>>>>>This is really strange. We didn't catch any activity from the patch
>>>
>>>so I >> don't know why it isn't expiring. Come to think of it we we
>>>should have >> at least got some kernel messages?
>>>
>>>>>What version was the kernel you originally saw this on?
>>>
> lfarkas> # rpm -q kernel kernel-2.6.14-1.1637_FC4
> lfarkas> kernel-2.6.14-1.1641_FC4.jmoyertest.1
> 
>>>
>>>>>Jeff, I'm wondering if this is a regression from the latest patch.
>>>
>>>Was >> that in the above kernel?
>>>
>>>>>Farkas, if your willing the next step in this process is likely to >>
>>>
>>>generate even more output but hopefully will give us more info.
>>>
> 
> lfarkas> what should i do?
> 
>>>Well, I shouldn't be rolling kernels so late in the day.  I didn't even
>>>apply the patch!  I'll roll another for you to try.  ;)
> 
> 
> raven> The interesting thing about the log is that there was no timeout and
> raven> instant remount activity which is characteristic of the GUI scaning
> raven> problem. AFAICT the reason that this happens is because the GUI
> raven> scaning springs into life when it sees the umount activity.
> 
> Good point.  Can we get the output of lsof and fuser -v?

a full lsof ? fuser -v for what?


-- 
  Levente                               "Si vis pacem para bellum!"

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to