hall and autofs

[Ian Kent]

On Sat, 2006-04-29 at 13:13 +0800, Ian Kent wrote:
> On Fri, 2006-04-28 at 18:17 +0200, Danny Kukawka wrote:
> > On Friday 28 April 2006 15:25, Ian Kent wrote:
> > [...]
> > > > We do something like this already on SUSE. We skip check e.g. NFS mounts
> > > > because this can freeze the hole hal and applications using HAL freeze or
> > > > fail, if you have NFS stale mountpoints in the system and because we
> > > > never provide infos in HAL about NFS mounts (hence, we don't need to stat
> > > > them).
> > > >
> > > > I attach the patch from SUSE against 0.5.6. If okay, I commit the patch
> > > > to CVS.
> > >
> > > I think that's only part of the difficulty.
> > >
> > > It's likely needed to skip anything under a filesystem type of "autofs"
> > > because within the autofs filesystem there can be cifs, NFS, bind mounts
> > > or whatever. These can be nested under certain circumstances.
> > >
> > > I think the current reported problem is where there is an automount
> > > trigger as an intermediate directory to the mount point being stat()ed.
> > > In this case the kernel module will see the LOOKUP_CONTINUE flag during
> > > the path walk and quite rightly mount the intervening filesystem.
> > 
> > What is the output of 'cat /proc/mounts' in this case? What is the listed 
> > filesystem in this case? autofs or the real filesystem? IMO there is the real 
> > fs listed, but not sure. Could you paste the output?
> 
> How about a debug trace from autofs as well.
> I'm using autofs development version 5 here but the symptom is the same.

Anyone considered this issue further?

I'm seeing it fairly reliably on FC-5 and have another report of someone
unable to umount their autofs managed CD on FC-5.

Ian