Bug 116873 - Timeouts Not Inherited by Submounts of Automount Daemon
Timeouts Not Inherited by Submounts of Automount Daemon
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: autofs (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-25 16:43 EST by ensafi
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-01 22:48:24 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)

  None (edit)
Description ensafi 2004-02-25 16:43:18 EST
Description of problem:

It appears that submounts (automount --submount /path/subpath 
map_type ...) do not inherit the timeout parameter of their parent 
mounts (automount --timeout seconds /path map_type ...), so they 
expire according to the default timeout of 5 minutes rather than the 
user-specified number of seconds.

Version-Release number of selected component (if applicable):

autofs-3.1.7-41

How reproducible:

Always.

Steps to Reproduce:
1. In /etc/auto.master:
/misc /etc/auto.misc --timeout=60
2. In /etc/auto.misc:
sub -fstype=autofs /etc/auto.sub
3. In /etc/auto.sub:
* some_valid_server:/some_valid_exported_path
4. Make sure that some_valid_server:/some_valid_exported_path is 
properly exported via /etc/exports on the appropriate server, and 
make sure that it can be manually mounted on the client 
where /etc/auto.sub has been installed
5. Restart autofs and cause /misc/sub/some_valid_exported_path to get 
mounted using the following command:
ls /misc/sub/some_valid_exported_path
6. Wait at least 1 minute, but no more than 4 minutes, and check to 
see if /misc/sub/some_valid_exported_path is still mounted using the 
following command:
df | grep /misc/sub/some_valid_exported_path

Actual results:

After 1 minute, the user-specified timeout in /etc/auto.master, the 
mounted path /misc/sub/some_valid_exported_path is still mounted.  
After 5 minutes, the autofs default timeout value, it gets 
unmounted.  Looking at the process table reveals that the parent 
automount daemon has the "--timeout 60" flag, but its child only has 
a "--submount" flag with no explicit timeout.  As a result, the 
parent remains mounted until the child gets unmounted after the 
default timeout period has elapsed.

Expected results:

All children of the parent automount daemon should inherit the "--
timeout 60" flag from their parents.  If this means re-examining 
the /etc/auto.master file, so be it, but there must be a more elegant 
way to communicate this timeout from the parent daemon to its 
children, and from its children to all of their grandchildren.

Additional info:

Nada.
Comment 1 ensafi 2004-02-26 19:59:20 EST
Step #6 of "Steps to Reproduce" was wrong.  Correction:

Do not use df as this will access the remote filesystem and prevent 
the automounter from unmounting.  Instead, check /etc/mtab directly 
to see if the path is still mounted as follows:

grep /misc/sub/some_valid_exported_path /etc/mtab

Also, it seems to me that it would be very simple for the automount 
daemon to inclue the appropriate "--timeout" flag when it spawns each 
of its children with the "--submount" flag.  This would be a quick, 
easy, and presumably safe fix.
Comment 2 Jeffrey Moyer 2004-03-22 15:14:08 EST
I'll look into this.
Comment 3 Jeffrey Moyer 2004-05-11 17:12:55 EDT
Autofs4 takes care of this, and we'll be moving to this in the next
update.
Comment 5 Jay Turner 2004-09-01 22:48:24 EDT
An errata 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/RHBA-2004-284.html

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