Created attachment 487261 [details] initial patch Description of problem: When /etc/auto.master file contains multiple direct map entries that are with --timeout option, automount uses the timeout value of the first entry to all the direct entries. Due to this behavior users cannot set the timeout value individually. Version-Release number of selected component (if applicable): autofs-5.0.1-0.rc2.143.el5.6 How reproducible: Always Steps to Reproduce: 1. Add following lines to /etc/auto.master: /- /tmp/nfs/test1.txt --timeout=30 /- /tmp/nfs/test2.txt --timeout=40 2. Create map files. Modify accordingly: # less /tmp/nfs/test1.txt /foo <mount_option> <NFS-server's_address>:TEST # less /tmp/nfs/test2.txt /bar <mount_option> <NFS-server's_address>:TEST2 3. Add DISABLE_DIRECT=0 to /etc/sysconfig/autofs 4. Restart autofs Actual results: cat /proc/mounts shows the following: /tmp/nfs/test2.txt /bar autofs rw,fd=18,pgrp=18876,timeout=30,minproto=5,maxproto=5,direct 0 0 /tmp/nfs/test1.txt /foo autofs rw,fd=18,pgrp=18876,timeout=30,minproto=5,maxproto=5,direct 0 0 Expected results: Timeout for /bar should be 40, not 30. Additional info: master_parse_entry() shares the options of that of the previous entry that has the same path. Thus, --timeout for the second direct map (in this case, /- /tmp/nfs/test2.txt) is ignored. The patch rules out direct entries, so every time /- is observed as a path it creates brand new entry. I'm not sure if the patch addresses other cases correctly, but at least for the suggested bug this should work. Please verify the patch and modify per required.
Yes, the timeout is currently associated with the map entry which means that there can't be separate timeouts for each direct mount map source. While this is a sensible and useful request it amounts to asking for the timeout to be moved from the map entry to the map source which isn't a trivial change. So I think doing this as an RFE is the correct classification. Ian
(In reply to comment #0) > Created attachment 487261 [details] > initial patch Seems this isn't quite as difficult as I originally thought but I'm sure I'm missing something, hopefully I'll pick it up during testing. > > Description of problem: > When /etc/auto.master file contains multiple direct map entries that are with > --timeout option, automount uses the timeout value of the first entry to all > the direct entries. Due to this behavior users cannot set the timeout value > individually. It turns out that the code has been written in a way that is amenable to adding additional master mapent structures for multiple direct map instances. Well, almost anyway, not quite a simple as the supplied patch, that's for sure. Hopefully it won't take too long to do. > > Version-Release number of selected component (if applicable): > autofs-5.0.1-0.rc2.143.el5.6 > > How reproducible: > Always > > Steps to Reproduce: > 1. Add following lines to /etc/auto.master: > /- /tmp/nfs/test1.txt --timeout=30 > /- /tmp/nfs/test2.txt --timeout=40 > > 2. Create map files. Modify accordingly: > # less /tmp/nfs/test1.txt > /foo <mount_option> <NFS-server's_address>:TEST > # less /tmp/nfs/test2.txt > /bar <mount_option> <NFS-server's_address>:TEST2 > > 3. Add DISABLE_DIRECT=0 to /etc/sysconfig/autofs This isn't relevant with version 5 as direct mounts work as expected so there's no need to imply people shouldn't use them with this configuration setting. Ian
I wasn't able to find the time to check the implications of this so we will need to defer it to RHEL-5.9. I did spend time on it but decided that I would need to defer it because I'm fairly sure there will be some problematic side effects from the change. But I haven't been able to identify what they are so far.
Created attachment 584525 [details] Patch - move timeout to map_source
A test package with the above patch is available at: http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.165.el5 Please test this package and report back.
Reproduced in autofs-5.0.1-0.rc2.164.el5 and verified in autofs-5.0.1-0.rc2.165.el5.
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. http://rhn.redhat.com/errata/RHSA-2013-0132.html