Created attachment 383182 [details] Output of looping abrtd Description of problem: abrtd loops, using 50%+ of cpu Version-Release number of selected component (if applicable): abrt-1.0.3-1.fc12.i686 How reproducible: Not, thankfully Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: This appears to be a side-effect of a selinux problem. However, no loops in a daemon, hopefully.
Looks like you have massive munber of deaths from SEGVs in grep, cat, date, sleep - just about anything. Then you rebooted the box. And then abrtd tried to process all those many dumps. Looks like at least logging needs fixing, with current state is is not clear whether it loops or not.
I improved logging - now it will tell how many directories are there to check at startup, and will report names of every found non-processed crashdump dir. So, in your scenario, you'll see in syslog: Checking for unsaved crashdumps (1234 dirs to check) and then maybe many Non-processed crashdump in /path/to/crashdump, saving into database
The analysis and fixes appear to be reasonable. Does abrtd process the dumps serially or does it spawn processes/threads to do each dump? What I have in mind is in the (user) panic that ensues seeing abrtd using 50% of the CPU one might not think of looking at syslog. And I would assume that killing abrtd would be unhelpful; that it would have to be disabled.
abrt-1.0.7-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/abrt-1.0.7-1.fc12
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update abrt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1598
abrt-1.0.7-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.