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:


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


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0462 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.