Bug 139950 (IT#54302)
| Summary: | slocate collects .automount files over nfs | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Steve Conklin <sconklin> |
| Component: | slocate | Assignee: | Miloslav Trmač <mitr> |
| Status: | CLOSED ERRATA | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | berrange, tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHSA-2005-346 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-08-17 15:50:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 156321, 156323 | ||
|
Description
Steve Conklin
2004-11-18 21:46:40 UTC
More from the Issue - simply adding /.automount won't solve the problem. -------------- But we are still seeing this issue. With further investigation this is how I believe we're seeing this issue. We have: /etc/auto-master CONTAINS /opt/corp/lb /etc/auto_loadbuild Directories exists as: /opt/corp -> /opt/soe /opt/soe/lb AS SUCH /opt/corp/lb exists and satisfies the auto map. A request is made for /opt/corp/lb/blablabla and the mount is established with an entry recorded in the /etc/mtab file as /opt/corp/lb/blablabla updatedb runs and correctly skips the /opt/corp/* stuff because of the entry in slocate.cron :: the added /opt/corp to the dash 'e' (-e) list. updatedb has not been told to skip /opt/soe stuff but was told to skip nfs filesystems. updatedb traverses /opt/soe and ends up recording everything (EVERYTHING even thrugh nfs) it finds there. However /opt/soe/lb is a mounted filesystem; WELL actually /opt/corp/lb is the mounted filesystem recorded in mtab but corp links to soe and soe actually owns the lb directory which got mounted. So updatedb's syntax to exlude nfs has been circumvented. This I think is a bug and in our environment needlessly causes network storms (of light weight data mind you:: just file names not file contents) traffic, performance issues with each machine that runs updatedb and also huge slocate.db files (as seen above 225Mg) [snip] Here is an update of this issues events this weekend after I removed the link entry "/opt/corp" from slocate.cron and replaced it with the directory enry /opt/soe Again the link /opt/corp points at /opt/soe [snip] NOTCIE the size [of the database] is now only 2.8Mg as opposed to 225Mg. [snip] SOCATE.CRON FILE LOOKS LIKE: [root@wcary468 cron.daily]# cat slocate.cron #!/bin/sh renice +19 -p $$ >/dev/null 2>&1 /usr/bin/updatedb -f "nfs,mvfs,smbfs,ncpfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net,/.automount,/opt/soe" [root@wcary468 cron.daily]# So it seems having a 'link name' in a 'mount path' can circumvent the checks for nfs mounted file systems that updatedb performs (whatever the nature of that check is). *** Bug 144921 has been marked as a duplicate of this bug. *** problem is that a symbolic link can hide an NFS mount from updatedb. For example, if /a/b is an NFS mount point and /a/linktob is a symbolic link to /a/b, updatedb will correctly NOT go down /a/b, but it will go down /a/linktob because it does not detect it as an NFS mount, presumably because the /a/linktob path is not in its list of NFS mounts. Will this fix prevent slocate from traversing nfs mounts that are symlinked? AFAICS, the scenario in comment #10 should not be a problem simply because updatedb never follows symbolic links to directories. The scenario in comment #2 indeed looks possible, but that's only because amd incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes only paths with no symbolic links there. Steve, please file a separate bug against am-utils about this behavior; I'm sorry I have not noticed this earlier. (In reply to comment #11) > The scenario in comment #2 indeed looks possible, but that's only because amd > incorrectly writes a non-canonical path to /etc/mtab; mount(8) writes > only paths with no symbolic links there. Steve, please file a separate > bug against am-utils about this behavior; I'm sorry I have not noticed > this earlier. Sorry again... it seems autofs has (had?) a similar problem, so slocate should handle symlinks in /etc/mtab correctly. It will be fixed together with the other automounting issues. We're seeing this happen when slocate accesses a symlink to an nfs mount point. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-345.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-346.html |