Bug 804783
| Summary: | [abrt] Segfault during LDAP 'services' lookup | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | James Cape <jamescape777> | ||||||||
| Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | ||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 16 | CC: | jhrozek, sbose, sgallagh, ssorce | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | abrt_hash:d719b9efcbdd52df88a87eb9a8be0d63eebf1c22 | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-03-30 15:22:01 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: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
James Cape
2012-03-19 18:47:26 UTC
Created attachment 571207 [details]
File: dso_list
Created attachment 571208 [details]
File: maps
Created attachment 571209 [details]
File: backtrace
Thanks for the bug report. Can you reproduce the issue? It looks from the backtrace that it's occurring while processing lookups for the NSS 'services' map, so probably it's being invoked implicitly by another process. If possible, could you add "debug_level = 6" to /etc/sssd/sssd.conf in the [domain/DOMAINNAME] section (substituting DOMAINNAME as appropriate) and restarting SSSD with 'systemctl restart sssd.service', reproduce the issue and then attach /var/log/sssd/sssd_DOMAINNAME.log to this BZ (either sanitized or as a private attachment)? That would help us track this down faster. Yes, this crash has taken out three of the four workstations which our users have installed it on so-far---we've reverted to 1.6.4 and are in the process of pinning the package now so users don't accidentally update to 1.8.1. Yesterday we were able to help it survive a bit longer if we put debug_level=0x7777 and timeout=1 in the domain section in the configs, but that didn't work on the workstation which was updated today. As these are people's actual workstations it's more important that they're working right now, but I'll attempt to re-update/reproduce in a minute. On my own system, I can reproduce this bug (sssd_be is restarted several times, then fails to come back on the last attempt, typically within 60 seconds) without debugging. With debug_level = 6, it's been fairly solid. For the machines that are failing, you can work around the problem by removing the 'sss' from the 'services:' line of /etc/nsswitch.conf. That should allow them to continue running SSSD 1.8.1 without hitting this issue. (In reply to comment #6) > On my own system, I can reproduce this bug (sssd_be is restarted several times, > then fails to come back on the last attempt, typically within 60 seconds) Yeah, if we detect the backend crashing that often, we stop trying to restart it. Strange behavior though. I'm guessing you must have some service in your environment that's querying the NSS 'service' map constantly. > without debugging. With debug_level = 6, it's been fairly solid. Could you examine those logs and see if you see a lot of repeated requests for the same information (specifically service information)? It's possible we have a race condition that the debug logs are hiding. (This just hit workstation #5) None of the machines have sss in the services line, and the only repeated requests I see in the logs for debug_level = 6 what looks like the initial user/group load. Ah, damn. I just noticed that this is happening during enumeration, not lookup. So we probably have an enumeration bug. I'll try to reproduce this. Sorry for the confusion. I'll dive into this first thing tomorrow. sssd-1.8.1-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/sssd-1.8.1-8.fc16 Still crashing, see #805566 Package sssd-1.8.1-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.8.1-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-4404/sssd-1.8.1-8.fc16 then log in and leave karma (feedback). Backtrace analysis found this bug to be similar to bug #805566, closing as duplicate. This comment is automatically generated. *** This bug has been marked as a duplicate of bug 805566 *** |