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 856296 - Duplicate enty for the /net map cause /etc/init.d/autofs stop to fail
Summary: Duplicate enty for the /net map cause /etc/init.d/autofs stop to fail
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: autofs
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: yanfu,wang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-11 16:45 UTC by Harold Miller
Modified: 2018-11-29 20:19 UTC (History)
2 users (show)

Fixed In Version: autofs-5.0.5-62.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 10:53:36 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Requested debug logs (8.92 KB, text/plain)
2012-09-20 14:18 UTC, Harold Miller 		no flags Details
Patch - fix null map entry order handling (2.24 KB, patch)
2012-09-25 05:55 UTC, Ian Kent 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0462 0 normal SHIPPED_LIVE autofs bug fix and enhancement update 2013-02-20 21:07:21 UTC

Description Harold Miller 2012-09-11 16:45:26 UTC 
Description of problem: 	

/etc/init.d/autofs stop

regularly fails on all our RHEL6.3 and also RHEL5.8 machines.

The script sends a -TERM signal to the automount process, but it refuses to exit for some reason. The only way to terminate the automount process is a -9 kill signal.


Version-Release number of selected component (if applicable):
regularly fails on all our RHEL6.3 and also RHEL5.8 machines.


How reproducible: Easily


Steps to Reproduce:
1. In /etc/auto.master default config, add:
/net   -hosts
2. In  NIS auto.master map to disable /net, add:
/net   -null
3.send a -TERM signal to the automount process
  
Actual results:it refuses to exit


Expected results: automount should exit


Additional info: Removing one of these gets rid of the hang on stopping autofs and also of the startup message

Sep  5 12:35:00 horus automount[4458]: state.c:606: assertion failed:
ap->state == ST_READY || ap->state == ST_EXPIRE
Sep  5 12:35:00 horus automount[4458]: nextstate:85: write failed Bad file
descriptor
Comment 3 Ian Kent 2012-09-12 00:55:22 UTC 
(In reply to comment #0)
> Description of problem: 	
> 
> /etc/init.d/autofs stop
> 
> regularly fails on all our RHEL6.3 and also RHEL5.8 machines.
> 
> The script sends a -TERM signal to the automount process, but it refuses to
> exit for some reason. The only way to terminate the automount process is a
> -9 kill signal.
> 
> 
> Version-Release number of selected component (if applicable):
> regularly fails on all our RHEL6.3 and also RHEL5.8 machines.
> 
> 
> How reproducible: Easily

Easy in your environment.

> 
> 
> Steps to Reproduce:
> 1. In /etc/auto.master default config, add:
> /net   -hosts
> 2. In  NIS auto.master map to disable /net, add:
> /net   -null
> 3.send a -TERM signal to the automount process
>   
> Actual results:it refuses to exit

I can't reproduce this problem with only these steps.

Also, the null map causes the next occurrance of the map to
be ignored not a previous entry. The above construct won't
work the way you expect.

> 
> 
> Expected results: automount should exit
> 
> 
> Additional info: Removing one of these gets rid of the hang on stopping
> autofs and also of the startup message
> 
> Sep  5 12:35:00 horus automount[4458]: state.c:606: assertion failed:
> ap->state == ST_READY || ap->state == ST_EXPIRE
> Sep  5 12:35:00 horus automount[4458]: nextstate:85: write failed Bad file
> descriptor

Needless ro say I don't see these either.

Ian
Comment 4 Ian Kent 2012-09-12 00:56:52 UTC 
How about posting a debug log and a copy of /proc/mounts both
before automount is started and after it has started.
Comment 5 Harold Miller 2012-09-12 18:42:04 UTC 
Ian,

Certainly. How do I have the customer generate the debug log you are requesting?

Harold
Comment 6 Ian Kent 2012-09-13 04:45:35 UTC 
(In reply to comment #5)
> Ian,
> 
> Certainly. How do I have the customer generate the debug log you are
> requesting?

First you need to ensure that syslog facility daemon, level
debug and higher are being recorded in syslog. I usually do
that by sending facility daemon to a seperate log file, for
example:

daemon.*                    /var/log/debug

Then you need to set autofs to generate debug log messages
by setting:

LOGGING="debug"

in /etc/sysconfig/autofs.

Ian
Comment 7 Harold Miller 2012-09-20 14:17:49 UTC 
From customer - "Attached please find the requested debug log. Note that the problem is trivial to reproduce in our environment, so let me know if your engineers need additional information. Basically they just need a NIS domain with a "/net -null" entry in the auto_master map + the default Redhat /etc/auto.master file." Logs attached as autofs.debug.85629
Comment 8 Harold Miller 2012-09-20 14:18:38 UTC 
Created attachment 614942 [details]
Requested debug logs
Comment 9 Ian Kent 2012-09-21 01:04:50 UTC 
It seems my setup wasn't quite right, I hadn't add nis to the
automount entry in nsswitch.conf.

I'm now abe to reproduce the problem and will investigate.
Comment 10 Ian Kent 2012-09-25 05:55:58 UTC 
Created attachment 616867 [details]
Patch - fix null map entry order handling
Comment 11 Ian Kent 2012-09-25 05:58:31 UTC 
A test package which includes the above patch and may resolve
the issue in this bug has been build and is available at:
http://people.redhat.com/~ikent/autofs-5.0.5-54.bz856296.1.el6_3

Please test the package and report back.
Comment 12 Harold Miller 2012-10-01 15:18:14 UTC 
Customer reports that test package appears  to have corrected this problem.
"I tried the rpm and it indeed looks like the issue is fixed. Thanks.

When can we expect this fix to be released as an official Redhat update?"
Comment 13 Ian Kent 2012-10-10 02:58:19 UTC 
(In reply to comment #12)
> Customer reports that test package appears  to have corrected this problem.
> "I tried the rpm and it indeed looks like the issue is fixed. Thanks.
> 
> When can we expect this fix to be released as an official Redhat update?"

I was waiting for feedback before committing this for rhel-6.4.

I've committed the change but the build failed due to a dependency
of a dependent package not being met. I'll wait a little while
before trying the build again, then mark this bug MODIFIED and set
the "fixed in" above.
Comment 15 yanfu,wang 2013-01-05 10:43:32 UTC 
hi Ian,
You said without using NIS, including another file map could reproduce the issue. I failed to reproduce it, so could I ask what's your configuration?
Comment 16 Ian Kent 2013-01-07 00:50:51 UTC 
(In reply to comment #15)
> hi Ian,
> You said without using NIS, including another file map could reproduce the
> issue. I failed to reproduce it, so could I ask what's your configuration?

What steps did you use?
Comment 17 yanfu,wang 2013-01-07 10:20:41 UTC 
(In reply to comment #16)
> (In reply to comment #15)
> > hi Ian,
> > You said without using NIS, including another file map could reproduce the
> > issue. I failed to reproduce it, so could I ask what's your configuration?
> 
> What steps did you use?

hi Ian,
I got the reason why I failed to reproduce it. The -null map must be specified in master map. With the correction, I could reproduce and verify it now:
Reproduced on 5.0.5-54.el6:
# cat /etc/auto.master
/home	/etc/auto.home
/home	-null
# service autofs start
Starting automount: [  OK  ]
# service autofs stop
Stopping automount: [FAILED]
# echo $?
0
# service autofs status
automount (pid  51659) is running...

/var/log/messages:
Jan  7 05:04:15 hp-dl388g8-06 automount[51338]: state.c:606: assertion failed: ap->state == ST_READY || ap->state == ST_EXPIRE
Jan  7 05:04:15 hp-dl388g8-06 automount[51338]: nextstate:85: write failed Bad file descriptor

Verified on 5.0.5-70.el6:
[root@hp-dl388g8-06 ~]# service autofs start
Starting automount: [  OK  ]
[root@hp-dl388g8-06 ~]# service autofs stop
Stopping automount: [  OK  ]
[root@hp-dl388g8-06 ~]# service autofs status
automount is stopped


Could you change the bug back to ON_QA, so I could modify the bug status to Verified? thanks.
Comment 18 yanfu,wang 2013-01-08 02:39:16 UTC 
Changed to verify against above testing.
Comment 19 errata-xmlrpc 2013-02-21 10:53:36 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.

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