RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1233057 - Direct map does not expire if map is initially empty
Summary: Direct map does not expire if map is initially empty
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: xiaoli feng
URL:
Whiteboard:
Depends On:
Blocks: 1233069 1268411 1335358
TreeView+ depends on / blocked
 
Reported: 2015-06-18 07:14 UTC by Ian Kent
Modified: 2016-05-12 04:32 UTC (History)
9 users (show)

Fixed In Version: autofs-5.0.5-122.el6
Doc Type: Bug Fix
Doc Text:
Cause: When autofs is started with an empty direct map the expire run frequency isn't known so an expire alarm isn't set. If the map is updated and is no longer empty and an autofs map re-loaded is done the expire alarm still isn't added. Consequence: In this case direct mounts do not expire. Fix: If the expire run frequency wasn't previously known add the expire alarm during the autofs map re-load. Result: Direct mounts expire as expected.
Clone Of:
: 1233069 1335358 (view as bug list)
Environment:
Last Closed: 2016-05-11 00:50:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Patch - fix direct map expire not set for initail empty map (1.57 KB, text/plain)
2015-06-18 07:14 UTC, Ian Kent 		no flags Details
Patch - don't schedule new alarms after readmap (1.91 KB, patch)
2016-04-06 11:15 UTC, Ian Kent 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0934 0 normal SHIPPED_LIVE autofs bug fix and enhancement update 2016-05-10 22:54:31 UTC

Description Ian Kent 2015-06-18 07:14:14 UTC 
Created attachment 1040288 [details]
Patch - fix direct map expire not set for initail empty map

Description of problem:
If an empty direct map is present at startup the expire alarm can't be
set because the expire run frequency isn't known. If the map is re-read
and is no longer empty the expire alarm isn't then set either.

Version-Release number of selected component (if applicable):
autofs.x86_64 1:5.0.5-109.el6

This problem was seen when working on bug 1227496 so a variation
of the steps to reproduce the bug of 1227496 can be used to
reproduce it.

Steps to Reproduce:
1. Set autofs to produce debug log output to syslog.

# grep debug /etc/autofs.conf
# logging - set default log level "none", "verbose" or "debug"
logging = debug

and ensure rsyslog is logging facility daemon output

# grep daemon /etc/rsyslog.conf
daemon.*		/var/log/debug

2. Add a direct mount map to auto.master.

# grep direct /etc/auto.master
/- /etc/auto.direct

3. Add a couple of entries to the direct mount map but leave
   them commented out.
# cat /etc/auto.direct 
#/test/s1	bilbo:/Public
#/test/s2	bilbo:/autofs

4. Start the autofs service

# service autofs start

Observe that there are no expire runs seen in the debug logging.
The expire run frequency is timeout/4 so if we don't see an expire
run within timeout time we know expres aren't happening.

But, since there are no mounts in the map the expire run frequency
isn't known so this is expected.

4. Modify /etc/auto.direct and uncomment the entries

# cat /etc/auto.direct 
/test/s1	bilbo:/Public
/test/s2	bilbo:/autofs

5. Reload the autofs maps

# service autofs reload

6. Access one of the direct mount map entries causing it
   to be mounted.

# ls /test/s1

7. Again observe that there are no expire runs seen in the
debug log and the above mount is never expired. Waiting
timeout time is sufficient to confirm this.

Actual results:
Direct mount is not expired.

Expected results:
Direct mount is expired and umounted roughly after timeout time
(although this could be as much as (timeout + timeout/4).
Comment 1 XuWang 2015-07-02 03:27:30 UTC 
Sorry, I can not reproduce it on autofs-5.0.5-109.el7. I both tried to add "timeout=10" to /etc/autofs.conf and "-t 10" to /etc/auto.master.

I think the following code will add the timeout alarm:

 323 static void do_readmap_cleanup(void *arg)
 324 {
 325     struct readmap_args *ra;
 326     struct autofs_point *ap;
 327 
 328     ra = (struct readmap_args *) arg;
 329 
 330     ap = ra->ap;
 331 
 332     st_mutex_lock();
 333 
 334     ap->readmap_thread = 0;
 335     st_set_done(ap);
 336     if (!ap->submount)
 337         alarm_add(ap, ap->exp_runfreq);
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here will add the ap timeout

And in function do_readmap, after the while(map) loop, the ap->exp_runfreq will not be 0, so the pthread_cleanup_pop(1) in line 522 will call the do_readmap_cleanup, and the timeout for this ap(/-) will be added.

And I also add some debug logs in do_readmap_cleanup, it seems to verify my analysis. I've no idea what I missed, can you give me some hints?
Comment 2 Ian Kent 2015-07-02 04:01:06 UTC 
(In reply to XuWang from comment #1)
> Sorry, I can not reproduce it on autofs-5.0.5-109.el7. I both tried to add
> "timeout=10" to /etc/autofs.conf and "-t 10" to /etc/auto.master.
> 
> I think the following code will add the timeout alarm:
> 
>  323 static void do_readmap_cleanup(void *arg)
>  324 {
>  325     struct readmap_args *ra;
>  326     struct autofs_point *ap;
>  327 
>  328     ra = (struct readmap_args *) arg;
>  329 
>  330     ap = ra->ap;
>  331 
>  332     st_mutex_lock();
>  333 
>  334     ap->readmap_thread = 0;
>  335     st_set_done(ap);
>  336     if (!ap->submount)
>  337         alarm_add(ap, ap->exp_runfreq);
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here will add the ap timeout
> 
> And in function do_readmap, after the while(map) loop, the ap->exp_runfreq
> will not be 0, so the pthread_cleanup_pop(1) in line 522 will call the
> do_readmap_cleanup, and the timeout for this ap(/-) will be added.
> 
> And I also add some debug logs in do_readmap_cleanup, it seems to verify my
> analysis. I've no idea what I missed, can you give me some hints?

That does seem appear to be the case so my comment about
it in bug 1233069 might be wrong.

Maybe I am mistaken, and maybe I didn't actually check revision
109, sorry.

I'll check, perhaps we can actually close this for RHEL-6 or
perhaps should raise a bug to add upstream commit f3dedc7b
and include this as part of it.

Ian
Comment 29 Ian Kent 2016-04-06 11:15:08 UTC 
Created attachment 1144194 [details]
Patch - don't schedule new alarms after readmap

Also needed for this change to ensure expire alarms do
not accumulate after read map processing.
Comment 31 Ian Kent 2016-04-06 12:44:47 UTC 
A new package has been built and added to the errata.
Comment 36 errata-xmlrpc 2016-05-11 00:50:39 UTC 
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.

https://rhn.redhat.com/errata/RHBA-2016-0934.html
Note You need to log in before you can comment on or make changes to this bug.