Bug 206705
| Summary: | mount.nfs returns success after a failed mount | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jeff Moyer <jmoyer> | ||||
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | rawhide | CC: | jmbastia, kzak, tao, triage | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | bzcl34nup | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-07 00:50:59 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: | |||||||
| Attachments: |
|
||||||
|
Description
Jeff Moyer
2006-09-15 19:53:19 UTC
Created attachment 136386 [details]
return errors from failed mounts
The patch in Comment #1 looks resonable... Feel free to apply it... OK, I walked through the error paths in mount and mount.nfs (and let me tell
you, it's hairy). I'm not sure that returning -1 from mount.nfs is a good idea,
as that error can be used as the return code from the mount process. Take a
look at do_mount_all, for example. It does this:
for (mc = cp->mec; mc; mc = mc->nxt) {
status |= mount_one (mc->m.mnt_fsname,
mc->m.mnt_dir,
mc->m.mnt_type,
mc->m.mnt_opts,
options, 0, 0);
}
Thus, if mount.nfs returns -1, that status can be propagated to this function,
which then essentially sets status to -1. Since -1 is not a documented return
code for mount, I think it should be avoided. This is especially true since the
return code is a bitmask, so a program checking for errors would find all error
flags set.
I think it's harmless, but it could lead to user confusion. If I'm reading the
code improperly, please let me know. Steve, could you please take a look at
this and let me know what the correct behaviour is?
Looking at the mount man pages the expect return code is is basically a int 32 value (or EX_FAIL). So as long as mount.nfs and mount.nfs4 exit with that value on failed mounts, we continue to be consistent with the man page... The above patch was added to nfs-utils-1.0.9-8 *** Bug 206208 has been marked as a duplicate of this bug. *** *** Bug 216153 has been marked as a duplicate of this bug. *** Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp This bug was actually fixed. |