Red Hat Bugzilla – Bug 215763
/etc/cron.daily/mlocate.cron triggers mount attempts for all automounted directories
Last modified: 2007-11-30 17:11:49 EST
Description of problem:
With the previous version of autofs/automount, the automounted directories
showed up in /proc/filesystems and so got added to the "nodevs" exclusion list.
With the new version, they don't. This causes updatedb to attempt to mount
every automounted directory, which I don't think is desired behavior.
The trick will be to get a list automounted directories from the automount
daemon. Not sure how this can be done now. CC'ing jmoyer for his input.
Version-Release number of selected component (if applicable):
$ grep autofs /proc/filesystems
$ rpm -q kernel
$ uname -r
$ rpm -q mlocate
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
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
(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
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.
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
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.