Bug 507031 - automount segfault on stopping daemon
automount segfault on stopping daemon
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.3
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Ian Kent
Red Hat Kernel QE team
:
Depends On: 513289
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-19 18:09 EDT by Shad L. Lords
Modified: 2011-03-30 03:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-30 03:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
core #1 (137.22 KB, application/gzip)
2009-06-19 18:11 EDT, Shad L. Lords
no flags Details
core #2 (74.15 KB, application/gzip)
2009-06-19 18:11 EDT, Shad L. Lords
no flags Details
core #3 (78.91 KB, application/gzip)
2009-06-19 18:12 EDT, Shad L. Lords
no flags Details

  None (edit)
Description Shad L. Lords 2009-06-19 18:09:39 EDT
Description of problem:

when issuing a "service autofs restart" many times automount will crash and dump an core file in the / directory

Version-Release number of selected component (if applicable):

autofs-5.0.1-0.rc2.102


How reproducible:

30% or more

Steps to Reproduce:
1. setup auto mounts 
2. restart autofs daemon
  
Actual results:

automount crashes and dumps core file

Expected results:

no crash or core file

Additional info:

The automount stop and restarts so it functionally does what it is supposed to.
Comment 1 Shad L. Lords 2009-06-19 18:11:38 EDT
Created attachment 348721 [details]
core #1
Comment 2 Shad L. Lords 2009-06-19 18:11:56 EDT
Created attachment 348722 [details]
core #2
Comment 3 Shad L. Lords 2009-06-19 18:12:12 EDT
Created attachment 348723 [details]
core #3
Comment 4 Shad L. Lords 2009-06-19 18:12:59 EDT
Directory output of core files uploaded:

[slords@b64-5 ~]$ ll /core.*
-rw------- 1 root root 10244096 Jun  4 14:35 /core.1343
-rw------- 1 root root  9469952 Jun  5 08:12 /core.1352
-rw------- 1 root root  9469952 Jun  4 21:54 /core.1365
Comment 5 Ian Kent 2009-10-08 00:04:32 EDT
Oh ... I seem to have let this slip through without attention,
sorry.

I'm not even going to try to setup a system to look at these
core files because it usually doesn't work, particularly for
64-bit cores.

But, we have seen plenty of gdb backtraces from customers for
this issue so I'm confident that if your usage is the same we
know about this bug and, although it proved to be an ongoing
problem and several attempts didn't quite fix it, I believe it
has finally been fixed in our current RHEL-5.4 release.

Basically, the issue should only happen if you are using LDAP
for your map storage. Is that the case?

You can view the errata that includes this correction at:
http://rhn.redhat.com/errata/RHBA-2009-1397.html

Can you test the current release?
Is there anything else that we need to do for this issue?

Ian
Comment 6 Shad L. Lords 2009-10-08 00:36:26 EDT
(In reply to comment #5)
> But, we have seen plenty of gdb backtraces from customers for
> this issue so I'm confident that if your usage is the same we
> know about this bug and, although it proved to be an ongoing
> problem and several attempts didn't quite fix it, I believe it
> has finally been fixed in our current RHEL-5.4 release.
> 
> Basically, the issue should only happen if you are using LDAP
> for your map storage. Is that the case?

I do store my maps in ldap.  Is that the only time it used to happen and 5.4 should fix it or it was fixed except for storing it in ldap?
 
> You can view the errata that includes this correction at:
> http://rhn.redhat.com/errata/RHBA-2009-1397.html
> 
> Can you test the current release?
> Is there anything else that we need to do for this issue?

I'll test the 5.4 release.  If you believe that it is fixed then go ahead and mark this as such and I'll reopen if it isn't.

Thanks.
Comment 7 Ian Kent 2009-10-08 01:38:53 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > But, we have seen plenty of gdb backtraces from customers for
> > this issue so I'm confident that if your usage is the same we
> > know about this bug and, although it proved to be an ongoing
> > problem and several attempts didn't quite fix it, I believe it
> > has finally been fixed in our current RHEL-5.4 release.
> > 
> > Basically, the issue should only happen if you are using LDAP
> > for your map storage. Is that the case?
> 
> I do store my maps in ldap.  Is that the only time it used to happen and 5.4
> should fix it or it was fixed except for storing it in ldap?

The problem is related to an unload of a library that the autofs
LDAP lookup module uses. We work around incorrect usage of pthreads
Thread Specific Data keys by the dependent library.

So, yes, it should be fixed in RHEL-5.4.

> 
> > You can view the errata that includes this correction at:
> > http://rhn.redhat.com/errata/RHBA-2009-1397.html
> > 
> > Can you test the current release?
> > Is there anything else that we need to do for this issue?
> 
> I'll test the 5.4 release.  If you believe that it is fixed then go ahead and
> mark this as such and I'll reopen if it isn't.

Be aware that, after we finally resolved this another problem
surfaced with the same library, in particular a non-thread-safe
function call in libxml2. It's fairly infrequent though and
requires a library re-load (possibly caused by a HUP signal to
re-read the maps) as well as multiple threads calling the
function at the same time.

We didn't get this correction into 5.4 but it has been fixed.

Ian
Comment 8 Ian Kent 2011-03-28 05:44:57 EDT
I believe this has been fixed as described in the comments above.
Is that the case?
Comment 9 Ian Kent 2011-03-30 03:30:57 EDT
If this is still a problem with the current release of autofs
please re-open this bug.

Note You need to log in before you can comment on or make changes to this bug.