On Fri, 7 Jul 2006, Latrell wrote:

> There will be an automount daemon for 1 ftp session (used to mount shares
> under home directory).
> I sent SIGTERM to automount when my FTP session close (because the
> corresponding automount daemod need to be killed).
> In my scenario, there should be multi-sessions need to be closed. Thus,
> SIGTERM will not be unique.

I'm a little confused.
What I was suggesting is that according to the log entry below automount 
received one of the above signals which caused the mount to fail. That was 
why I asked about where the signals might have come from. If you send a 
termination signal to version 4 and a mount is busy it usually won't exit 
but I would expect any mounts in progress to fail in this manner as well.

> 
> My autofs version is 4.1.4 with patch autofs4-2.4.29-20050404.patch.
> kernel is 2.4.31 (no autofs patch for 2.4.31)

You should consider appling the patches for 4.1.4 available on kernel.org.
At least apply autofs-4.1.4-locking-fix-1.patch.
However, the locking problem that this addresses results in lock timeout 
log entries not lock interrupted messages. The reason bieng that automount 
dosn't wiat for the lock.

> 
> Thanks, for your comment,
> Latrell.
> ----- Original Message ----- From: "Ian Kent" <[EMAIL PROTECTED]>
> To: "Latrell" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>; <[email protected]>
> Sent: Thursday, July 06, 2006 7:58 PM
> Subject: Re: [autofs] Large number of mount request.
> 
> 
> > On Thu, 2006-07-06 at 11:52 +0800, Latrell wrote:
> > > Do you mean my ghost option didn't make it in time thus "cd share1"
> > > failed?
> > > I got the following message whenever there's "Failed to change directory"
> > > error:
> > > 
> > > automount[2306]: aquire_lock: can't lock lock file interrupted:
> > > /var/lock/autofs
> > 
> > And what is sending the SIGQUIT, SIGTERM or SIGINT to autofs to cause it
> > to stop waiting and return a interrupted fail?
> > 
> > > automount[2306]: failed to mount autofs path /tmp/users/shares/1034
> > > 
> > > automount[2306]: /ramdisk/mnt/var1/tmp/users/shares/1034: mount failed!
> > > 
> > > I also checked the ghost did create directory share1 under the home
> > > directory. Could the lock problem cause cd share1 fail?
> > > 
> > > Thanks for your comment,
> > > Latrell.
> > > 
> > > ----- Original Message ----- From: "ramana" <[EMAIL PROTECTED]>
> > > To: "Latrell" <[EMAIL PROTECTED]>; <[email protected]>
> > > Sent: Friday, June 23, 2006 7:27 PM
> > > Subject: Re: [autofs] Large number of mount request.
> > > 
> > > 
> > > > --- Latrell <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> Hi, all:
> > > >>
> > > >> I have a problem with the mount and umount packet.
> > > >> My problem is when I have a large number of mount requests, some
> > > >> mount request packets are missing. Thus, when I "cd share1", I will
> > > >> get "fail to change directory" because share1 is not mounted. Fewer
> > > >> mount requests work normally.
> > > >
> > > > I am afraid, this is ENOENT bug.
> > > >
> > > > Thanks in advance.
> > > >
> > > > Regards
> > > > ramana
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > > http://mail.yahoo.com
> > > >
> > > 
> > > _______________________________________________
> > > autofs mailing list
> > > [email protected]
> > > http://linux.kernel.org/mailman/listinfo/autofs
> > 
> 
> _______________________________________________
> autofs mailing list
> [email protected]
> http://linux.kernel.org/mailman/listinfo/autofs
> 

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

Reply via email to