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