Bug 215763 - /etc/cron.daily/mlocate.cron triggers mount attempts for all automounted directories
/etc/cron.daily/mlocate.cron triggers mount attempts for all automounted dire...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mlocate (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-15 12:07 EST by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 0.15-0.fc6.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-27 15:05:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Make mlocate use /proc/mounts instead of /tec/mtab (593 bytes, patch)
2006-11-15 20:42 EST, Ian Kent
no flags Details | Diff

  None (edit)
Description Orion Poplawski 2006-11-15 12:07:50 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):
mlocate-0.14-2.1
Comment 1 Jeff Moyer 2006-11-15 12:23:20 EST
$ 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?
Comment 2 Orion Poplawski 2006-11-15 12:41:15 EST
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.  
Comment 3 Jeff Moyer 2006-11-15 13:07:57 EST
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?
Comment 4 Miloslav Trmač 2006-11-15 20:38:14 EST
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.
Comment 5 Ian Kent 2006-11-15 20:42:56 EST
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.
Comment 6 Ian Kent 2006-11-15 23:36:50 EST
(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
Comment 7 Miloslav Trmač 2006-11-17 19:49:11 EST
Thanks for the explanation, mlocate-0.15-1 uses /proc/self/maps.
Comment 8 Ian Kent 2006-11-17 21:28:55 EST
(In reply to comment #7)
> Thanks for the explanation, mlocate-0.15-1 uses /proc/self/maps.

Don't you mean /proc/self/mounts?
Comment 9 Miloslav Trmač 2006-11-17 21:30:54 EST
(In reply to comment #8)
> Don't you mean /proc/self/mounts?
Yes, sorry about the thinko.
Comment 10 Orion Poplawski 2006-11-20 12:28:46 EST
Can we get a FC6 version?  I don't want to upgrade any more machines until this
is fixed.
Comment 11 Miloslav Trmač 2006-11-26 06:58:41 EST
Sure.
Comment 12 Fedora Update System 2006-11-27 10:43:43 EST
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.

Note You need to log in before you can comment on or make changes to this bug.