Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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).
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?
(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
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.
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