Bug 466673 - RFE: Make "intr" default option for /net -hosts mounts
RFE: Make "intr" default option for /net -hosts mounts
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Ian Kent
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-12 11:48 EDT by Ray Van Dolson
Modified: 2009-09-02 07:58 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
previously, the version of autofs shipped with Red Hat Enterprise Linux 5 used the "-hosts" method as its default way to handle /net mounts. Using this method, it was necessary to reboot the client to release processes if if the connection to the server was lost. Now, autofs uses the "intr" option as its default, which allows the mount to be unmounted forcibly if necessary.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 07:58:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1397 normal SHIPPED_LIVE autofs bug fix update 2009-09-01 08:02:15 EDT

  None (edit)
Description Ray Van Dolson 2008-10-12 11:48:14 EDT
Description of problem:
In previous versions of autofs (for example the one included with RHEL4), /net mounts were handled by the script /etc/auto.net.  This resulted in the "intr" option being used as a default option.

In RHEL5, although /etc/auto.net is still available, the -hosts method is the new default and does not make use of "intr".

Version-Release number of selected component (if applicable):
autofs-5.0.1-0.rc2.88

How reproducible:
Always

Steps to Reproduce:
1. cd /net/someserver/someexport
2. cat /proc/mounts
  
Actual results:
The export is not mounted using the intr option.

Expected results:
/etc/auto.net behavior with intr option passed.

Additional info:
It is simple to override this by changing th /net line in /etc/auto.master to:

/net   -hosts intr

However, I think intr is a sane default (and was in place in prior versions).  It'd be nice to have this be a default instead of needing to have kickstart set it up for all our installs.
Comment 1 Ian Kent 2008-10-20 12:17:01 EDT
I don't understand what difference you believe this will make?
What difference in behaviour have you actually observed?
Comment 2 Ray Van Dolson 2008-10-20 12:43:11 EDT
This would allow us to forcibly unmount hard mounted NFS mounts waiting on IO response from a server that has gone away.  This way we wouldn't need to reboot the client to clear up processes under this category.

I'm happy enough to override the defaults if needed, but a question for you:

What was the rationale behind changing the default from "intr" to without it between RHEL4 and RHEL5 automounter?
Comment 3 Ian Kent 2008-10-20 13:07:15 EDT
(In reply to comment #2)
> This would allow us to forcibly unmount hard mounted NFS mounts waiting on IO
> response from a server that has gone away.  This way we wouldn't need to reboot
> the client to clear up processes under this category.
> 
> I'm happy enough to override the defaults if needed, but a question for you:
> 
> What was the rationale behind changing the default from "intr" to without it
> between RHEL4 and RHEL5 automounter?

So your saying that will enable you to kill the mount process trying
to perform the mount in this case?

The change wasn't intentional, I had too many other things on my mind
during the development of version 5 and it slipped through.
Comment 4 Ray Van Dolson 2008-10-20 15:00:24 EDT
I totally understand; I was just curious if there was a reason for it and perhaps I should *not* be using intr.

We have cases where users start scripts based on data under /net/servername/ paths and then do funky stuff on the servername server either breaking the NFS daemon there or deleting or mangling data that is in use.  I'd at least like to be able to kill these processes and potentially unmount the associated /net/servername filesystem without having to reboot the system.

Obviously user education would help as well. :-)

Thanks!
Comment 5 Ian Kent 2008-10-20 18:28:52 EDT
(In reply to comment #4)
> I totally understand; I was just curious if there was a reason for it and
> perhaps I should *not* be using intr.
> 
> We have cases where users start scripts based on data under /net/servername/
> paths and then do funky stuff on the servername server either breaking the NFS
> daemon there or deleting or mangling data that is in use.  I'd at least like to
> be able to kill these processes and potentially unmount the associated
> /net/servername filesystem without having to reboot the system.

Yep, I understand.

Manually umounting stuff under a multiple mount like this will
cause various problems. You should avoid it.
Comment 7 Ian Kent 2009-05-20 22:57:39 EDT
This issue has been fixed in the latest autofs package
autofs-5.0.1-0.rc2.125.

The autofs RHTS test bugzillas/bz410051 has been updated to
to verify this correction.
Comment 11 Ruediger Landmann 2009-08-30 23:37:42 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
previously, the version of autofs shipped with Red Hat Enterprise Linux 5 used the "-hosts" method as its default way to handle /net mounts. Using this method, it was necessary to reboot the client to release processes if if the connection to the server was lost. Now, autofs uses the "intr" option as its default, which allows the mount to be unmounted forcibly if necessary.
Comment 12 errata-xmlrpc 2009-09-02 07:58:59 EDT
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 therefore 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/RHBA-2009-1397.html

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