Bug 1358887
| Summary: | On Red Hat 7.x systems if you try to access local filesystems using the automounter through /net then the shell and mount could lock up *if* the filesystem your accessing is double exported. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ashima Rawat <arawat> | ||||||
| Component: | autofs | Assignee: | Ian Kent <ikent> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Kun Wang <kunwan> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | high | ||||||||
| Version: | 7.0 | CC: | arawat, dwysocha, ikent, lmiksik, plambri, rhandlin, sfroemer, swhiteho, tomek, xzhou | ||||||
| Target Milestone: | rc | Keywords: | Reproducer | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | autofs-5.0.7-97.el7 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 1613630 (view as bug list) | Environment: | |||||||
| Last Closed: | 2018-10-30 11:41:29 UTC | Type: | Bug | ||||||
| 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: | 1613630 | ||||||||
| Attachments: |
|
||||||||
|
Description
Ashima Rawat
2016-07-21 17:25:23 UTC
(In reply to Ashima Rawat from comment #0) > Description of problem: > > On Red Hat 7.x systems if you try to access local filesystems using the > automounter through /net then the shell and mount could lock up *if* the > filesystem your accessing is double exported. > > Version-Release number of selected component (if applicable): > > RHEL 7.0 > > > How reproducible: > Export the shares and then try to access local filesystems using the > automounter through /net. > > > Steps to Reproduce: > 1. Exported the shares on RHEL 7.2 machine identical as yours. > > [root@dhcp8-30 ~]# exportfs -rav > exporting *:/tmp > exporting *:/export > exporting *:/ What is in /etc/exports? Below is the entry from exportfs file: # cat /etc/exports / *(rw,insecure,async) /export *(rw,insecure,async) /tmp *(rw,insecure,async) Also autofs debugging logs during the time of issue: Jul 22 08:02:17 dhcp8-30 automount[1219]: st_expire: state 1 path /net Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_proc: exp_proc = 140522986755840 path /net Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: got thid 140522986755840 path /net stat 0 Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp 140522986755840 finished, switching from 2 to 1 Jul 22 08:02:17 dhcp8-30 automount[1219]: st_ready: st_ready(): state = 2 path /net Jul 22 08:02:18 dhcp8-30 automount[1219]: st_expire: state 1 path /misc Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_proc: exp_proc = 140522986755840 path /misc Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: got thid 140522986755840 path /misc stat 0 Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp 140522986755840 finished, switching from 2 to 1 (In reply to Ashima Rawat from comment #4) > Also autofs debugging logs during the time of issue: > > Jul 22 08:02:17 dhcp8-30 automount[1219]: st_expire: state 1 path /net > Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_proc: exp_proc = > 140522986755840 path /net > Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: got thid > 140522986755840 path /net stat 0 > Jul 22 08:02:17 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp > 140522986755840 finished, switching from 2 to 1 > Jul 22 08:02:17 dhcp8-30 automount[1219]: st_ready: st_ready(): state = 2 > path /net > Jul 22 08:02:18 dhcp8-30 automount[1219]: st_expire: state 1 path /misc > Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_proc: exp_proc = > 140522986755840 path /misc > Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: got thid > 140522986755840 path /misc stat 0 > Jul 22 08:02:18 dhcp8-30 automount[1219]: expire_cleanup: sigchld: exp > 140522986755840 finished, switching from 2 to 1 I doubt that is what is in the log at the time of the mount attempt. What I see in the log is the mount(8) bind mount command hang but that is on an xfs file system. What file system is this? Which file system is this being seen on? Clearly I can't try and duplicate this if I don't know that. (In reply to Ian Kent from comment #6) > Which file system is this being seen on? > Clearly I can't try and duplicate this if I don't know that. Never mind, I don't think this is file system specific and it definitely isn't related to NFS either. Here's an update on what I've found so far.
The problem isn't related to NFS.
It isn't related to autofs either.
It is due to the root file system being set propagation shared
at boot by systemd.
First let me explain what autofs does for its multi-mount map
entries.
Consider an auto.master entry:
/multi /etc/auto.test
and an /etc/auto.test which contains:
test / server:/exports \
/tmp server:/exports/tmp \
/lib server:/exports/lib
where the directories /exports, /exports/tmp and /exports/lib
exist.
This is called a multi-mount entry and the individual mounts
of the sub paths are called offsets.
You can see that the root offset (/) is not an autofs file
system which means the offsets, /tmp and /lib, are no longer
within an autofs file system and won't be able to trigger
a mount.
In order to trigger offset mounts an autofs trigger mount
is mounted at each offset.
Now, if server is the local machine autofs will attempt to
bind mount them instead of NFS mounting them.
Assume that all three paths, /exports, /exports/tmp and
/exports/lib are within the root file system.
Then run "ls /multi/test".
This will result in a bind mount of <root fs device> on
/multi/test and two autofs trigger mounts on /multi/test/lib
and /multi/test/tmp.
Because the file system containing these two offset mounts is
shared (mounts propagate in both directions, to the parent
and slaves) both of these autofs mounts will propagate back
to the root file system as mounts of /exports/lib and
/exports/tmp neither of which are managed by automount(8)
effectively blocking access by the actual trigger mounts
when they are accessed.
Running "mount --make-rprivate /" or "mount --make-rslave /"
and performing the above accesses results in the automount(8)
functioning as expected.
If /exports/lib and /exports/tmp are separate file systems
then the extra mounts are propagated along with another
for each that covers the propagated autofs trigger mount
resulting in the multi-mount working but with extra unwanted
mounts due to the propagation.
So far it does not seem possible to change this behaviour
by having automount(8) use mount options related to mount
propagation.
It may be possible to change automount(8) (I'm thinking
about how I might do that now) to make the situation a
little better behaved but there is no way to avoid these
propagated mounts that I can see.
Ian
(In reply to Ian Kent from comment #10) > > If /exports/lib and /exports/tmp are separate file systems > then the extra mounts are propagated along with another > for each that covers the propagated autofs trigger mount > resulting in the multi-mount working but with extra unwanted > mounts due to the propagation. In the above I mean that /exports/lib and /exports/tmp are separate "local" file systems. Since the case here relates to the autofs hosts map, which essentially creates a multi-mount entry from the server exports list, a work around is to add the "nobind" option to the master map entry for the hosts map. For example: /net -hosts nobind which will avoid bind mounting and use NFS for mounting instead, and will work as expected. There is no workaround for colon escaped local paths, for example the multi-mount entry: test / :/exports \ /tmp :/exports/tmp \ /lib :/exports/lib will not work properly in the way described in comment #10. *** Bug 1596154 has been marked as a duplicate of this bug. *** Created attachment 1458628 [details]
Patch - set bind mount as propagation slave
Created attachment 1458629 [details]
Patch - add master map pseudo options for mount propagation
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3283 The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |