Bug 856296

(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

How about posting a debug log and a copy of /proc/mounts both
before automount is started and after it has started.

Ian,

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

Harold

(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

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

Created attachment 614942 [details]
Requested debug logs

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.

Created attachment 616867 [details]
Patch - fix null map entry order handling

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.

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?"

(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.

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?

(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?

(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.

Changed to verify against above testing.

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