Bug 215763

$ grep autofs /proc/filesystems
nodev   autofs
$ rpm -q kernel
kernel-2.6.18-1.2849.fc6
$ uname -r
2.6.18-1.2849.fc6
$ rpm -q mlocate
mlocate-0.14-2.1

Are you sure that your root-cause analysis is correct?  Autofs shows up in
/proc/filesystems for me as nodev.  Or did you mean that the automount file
systems showed up in /etc/mtab?  The new behaviour is for the autofs file
systems to only appear in /proc/mounts, not /etc/mtab.

I'd like to understand the problem a bit better before making any suggestions. 
Could you please answer my questions above?

Oops, looks like it the the mtab change that is at fault.  updatedb uses
setmntent()/getmntent() to see if the path is a mount point, which according to
the man page uses /etc/mtab.  

This looks like another place where libmount would be beneficial.

At any rate, can we modify updatedb et. al. to use /proc/mounts instead of
/etc/mtab?

Sure, updatedb can be changed, and /proc/mounts is indeed more reliable.

OTOH I wonder why autofs doesn't update /etc/mtab at all.  I can see why autofs
intentionally ignores the "writing mtab failed" error code of mount(8), but IMHO
it should at least try to update /etc/mtab (and ignore the error).

Just yesterday I was quite confused by the fact that automounted filesystems
didn't appear in the output of mount(8) while I was using them.

Created attachment 141329 [details]
Make mlocate use /proc/mounts instead of /tec/mtab

I've seen this happen a couple of times now but hadn't had
time to investigate. However, setmentent works fine with
/proc/mounts.

(In reply to comment #4)
> OTOH I wonder why autofs doesn't update /etc/mtab at all.  I can see why autofs
> intentionally ignores the "writing mtab failed" error code of mount(8), but IMHO
> it should at least try to update /etc/mtab (and ignore the error).

There are a number of reasons for this:

1) This is the usual behavior of Unix automounters.
2) autofs version 5 uses a lot of internal autofs mounts to
   implement "on demand" mount and expire of, possibly nested,
   multi-mounts (the implementation is similar to that used in
   other automounters). This has the effect of cluttering 
   the output of mount significantly and will rapidly lead to
   much more confusion for those not familiar with this.
3) The direct mount implementation uses an autofs mount as a
   trigger for every direct mount point in the map (again,
   in a similar way to other automounters). Similarly, this
   would lead to the same potential confusion as mentioned in
   2 above.
4) autofs version 5 no longer uses mount(8) to mount and umount
   the autofs filesystems it uses. It now uses mount(2),
   umount(2) and umount2(2) which don't update the mtab. This
   is much faster for large direct maps and reduces contention
   for mtab considerably.
5) For sites with a large number of direct mounts and possibly
   a large number of active mounts having all the entries in the
   mtab can lead to performance problems. For example we need to
   check for the presence of a "real" mount on a potential mount
   point for every mount so if all the autofs mounts appear in
   the mtab as well as real mounts this can kill performance.

Can't think of other reasons atm.

Ian

Thanks for the explanation, mlocate-0.15-1 uses /proc/self/maps.

(In reply to comment #7)
> Thanks for the explanation, mlocate-0.15-1 uses /proc/self/maps.

Don't you mean /proc/self/mounts?

(In reply to comment #8)
> Don't you mean /proc/self/mounts?
Yes, sorry about the thinko.

Can we get a FC6 version?  I don't want to upgrade any more machines until this
is fixed.

Sure.

mlocate-0.15-0.fc6.1 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.