Bug 507031
Summary: | automount segfault on stopping daemon | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Shad L. Lords <slords> | ||||||||
Component: | autofs | Assignee: | Ian Kent <ikent> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Red Hat Kernel QE team <kernel-qe> | ||||||||
Severity: | low | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 5.3 | CC: | ikent, jmoyer | ||||||||
Target Milestone: | rc | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2011-03-30 07:30:57 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | 513289 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Shad L. Lords
2009-06-19 22:09:39 UTC
Created attachment 348721 [details]
core #1
Created attachment 348722 [details]
core #2
Created attachment 348723 [details]
core #3
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 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 (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. (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 I believe this has been fixed as described in the comments above. Is that the case? If this is still a problem with the current release of autofs please re-open this bug. |