Bug 1434600
Summary: | autofs Doesn't Work on First Access | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jamie Jackson <jamiejaxon> |
Component: | autofs | Assignee: | Ian Kent <ikent> |
Status: | CLOSED WONTFIX | QA Contact: | xiaoli feng <xifeng> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.8 | CC: | eguan, ikent, jamiejaxon, mszeredi, xifeng, xzhou |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-12-06 12:27:48 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: |
Description
Jamie Jackson
2017-03-21 21:41:04 UTC
Can you provide a debug log. Include from autofs start through duplicating the problem please. * Let the first access hang: https://gist.github.com/jamiejackson/c14edd9d6e333452bc1909698517f27e * SIGINT the first access and try a second: https://gist.github.com/jamiejackson/8b31aeef0d3f7d07b73c9d9e26aa3a76 (In reply to Jamie Jackson from comment #3) > * Let the first access hang: > https://gist.github.com/jamiejackson/c14edd9d6e333452bc1909698517f27e > * SIGINT the first access and try a second: > https://gist.github.com/jamiejackson/8b31aeef0d3f7d07b73c9d9e26aa3a76 It looks like the mount(8) call to mount the fuse file system never returns. Miklos, can you tell me how fuse mounts like this are expected to behave please. Hanging is not the expected behavior. Can reporter try adding "debug,sshfs_debug,loglevel=debug" mount options to see how far it gets before it hangs? (In reply to Jamie Jackson from comment #0) > > /mnt/non-co/client_a /etc/auto.client_a_sshfs > uid=492,gid=488,--timeout=30,--ghost,--debug > ------------------------ > > auto.client_a_sshfs: > ------------------------ > testsftp -fstype=fuse,rw,nodev,noatime,debug > :sshfs\#redacteduser@redactedhost\:/export/home/files > ------------------------ Does the debug option, passed to mount(8), for the fuse mount also imply a foreground option, causing mount(8) to never actually return?
> Does the debug option, passed to mount(8), for the fuse mount
> also imply a foreground option, causing mount(8) to never actually
> return?
Exactly. I was thinking about the same thing just now. But then how does the second instance succeed?
(In reply to Miklos Szeredi from comment #7) > > Does the debug option, passed to mount(8), for the fuse mount > > also imply a foreground option, causing mount(8) to never actually > > return? > > Exactly. I was thinking about the same thing just now. But then how does > the second instance succeed? Presumably the mount has succeeded so the initiator waits for mount(8) to return and other accesses (from other processes) will just follow the mount, not calling back to autofs. (In reply to Ian Kent from comment #8) > (In reply to Miklos Szeredi from comment #7) > > > Does the debug option, passed to mount(8), for the fuse mount > > > also imply a foreground option, causing mount(8) to never actually > > > return? > > > > Exactly. I was thinking about the same thing just now. But then how does > > the second instance succeed? > > Presumably the mount has succeeded so the initiator waits for > mount(8) to return and other accesses (from other processes) > will just follow the mount, not calling back to autofs. Hang on, maybe I'm not correct about that. The callback is synchronous so if it hasn't returned the mountpoint should still be marked pending and that should block path walks ..... I'll need to have a look at that. (In reply to Miklos Szeredi from comment #5) > Hanging is not the expected behavior. > > Can reporter try adding "debug,sshfs_debug,loglevel=debug" mount options to > see how far it gets before it hangs? Extra mount debugging options added: https://gist.github.com/jamiejackson/3ed0c558021d039699ba01b60d10b727 What about if you remove all debug options? The debug option might be responsible for the hanging. (In reply to Miklos Szeredi from comment #11) > What about if you remove all debug options? > > The debug option might be responsible for the hanging. With debugging mount options removed, the problem seems to go away. I'm going to be testing some more, but I think the problem is solved. Thank you! Side question: Although I didn't necessarily think I'd found a bug, I didn't know where to go for autofs support. While your replies were quick here (thank you), is there another place (mailing list, IRC, forum, etc.) to ask questions if I need mundane help with this stuff in the future? (In reply to Jamie Jackson from comment #12) > (In reply to Miklos Szeredi from comment #11) > > What about if you remove all debug options? > > > > The debug option might be responsible for the hanging. > > With debugging mount options removed, the problem seems to go away. I'm > going to be testing some more, but I think the problem is solved. Thank you! That's good to hear. I'll still have a look at this (although time is short just now) though since I think other accesses to the mount should block the same way as the process that triggered the mount. > > Side question: Although I didn't necessarily think I'd found a bug, I didn't > know where to go for autofs support. While your replies were quick here > (thank you), is there another place (mailing list, IRC, forum, etc.) to ask > questions if I need mundane help with this stuff in the future? See /usr/share/doc/autofs/README, at the bottom. Some of it is a bit out of date but the mailing list info is accurate. The list is not very active these days so don't be surprised if it's quiet. Note Bug 1436322 (missing mailing list). (In reply to Jamie Jackson from comment #14) > Note Bug 1436322 (missing mailing list). We'll deal with that in Bug 1436322. (In reply to Jamie Jackson from comment #10) > (In reply to Miklos Szeredi from comment #5) > > Hanging is not the expected behavior. > > > > Can reporter try adding "debug,sshfs_debug,loglevel=debug" mount options to > > see how far it gets before it hangs? > > Extra mount debugging options added: > > https://gist.github.com/jamiejackson/3ed0c558021d039699ba01b60d10b727 I'm not sure that the automount(8) log reflects the actual order of events wrt. the kernel. Since a signal has been sent to the blocked process (which should wake up the waiters and complete the request in the kernel) the pending flag has probably been cleared allowing walks into the mount that has been completed. But the user space daemon mount request thread will still be waiting for the mount execution to complete. It might be worth checking if not sending a signal to the blocked process and seeing if other processes are blocked. Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. The official life cycle policy can be reviewed here: http://redhat.com/rhel/lifecycle This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL: https://access.redhat.com/ |