Bug 958968

Summary: Trying to report older crashes results in "Error: no processing is specified for event 'report-cli'" with libreport 2.1.3 / 2.1.4
Product: [Fedora] Fedora Reporter: Adam Williamson <awilliam>
Component: libreportAssignee: Jiri Moskovcak <jmoskovc>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 19CC: abrt-devel-list, dfediuck, dvlasenk, jfilak, jmoskovc, mlichvar, mmilata, mnowak, mtoman
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: gnome-abrt-0.3.1-1.fc19 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-15 00:55:22 UTC Type: Bug
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 Flags
offending oops none

Description Adam Williamson 2013-05-02 19:57:31 UTC
This is an F18 system, which is getting the whole new abrt/gnome-abrt/libreport clump as updates from updates-testing. With the newer libreport - 2.1.3 from updates-testing, or 2.1.4 from koji - trying to report any of my existing reports except the very latest seems to give this kind of result:

[root@vaioz adamw]# abrt-cli report /var/tmp/abrt/oops-2013-03-12-14\:26\:53-2663-2/
Error: no processing is specified for event 'report-cli'

The very latest I have 'works' better (I dunno why my kernel is tainted, but eh):

[root@vaioz adamw]# abrt-cli report /var/tmp/abrt/oops-2013-04-08-15\:00\:19-3824-1/
('report_uReport' completed successfully)
A kernel problem occurred, but your kernel has been tainted (flags:GW). Kernel maintainers are unable to diagnose tainted reports.

jmoskovc says this is a bug in libreport.

Comment 1 Jiri Moskovcak 2013-05-03 07:40:07 UTC
Kernel is tainted after the first oops, flags:GW means that there was already oops before this one. So to translate this - only the first oops after the reboot is reportable.

This line: Error: no processing is specified for event 'report-cli' menas that there is actually no action defined for oops when reporting from cli, which IS a bug.

Comment 2 Jiri Moskovcak 2013-05-03 08:42:56 UTC
I can't reproduce it, can you please send me the problem directory holding this kernel oops? I have a feeling it's the same cause as the '??' problem - the oops has been detected while the machine was shutting down, so the data is incomplete.

Comment 3 Adam Williamson 2013-05-03 17:16:14 UTC
Created attachment 743299 [details]
offending oops

Comment 4 Adam Williamson 2013-05-03 17:17:52 UTC
Note gnome-abrt does detect some oopses as incomplete and print a message to that effect in its GUI, but it does not do so for this one. This one shows up in gnome-abrt as "This problem hasn't been reported to Bugzilla yet, our developers..." and the Report button is active, but clicking it causes nothing to happen.

Comment 5 Jiri Moskovcak 2013-05-06 14:01:34 UTC
Ok, after closer look - the problem is incomplete but it seems like it's not because it wasn't fully written (which ABRT is capable of detecting), but it's partially deleted, any idea how this could happen (tmp clean, out of the quota..)

Comment 6 Adam Williamson 2013-05-06 17:50:38 UTC
I have 18GB of space available in the / partition, and I don't think any kind of 'cleaning' is done on /var/tmp (I think that's kinda the point of /var/tmp ). So I can't see any my-side explanations of why the report is incomplete, no. Regardless of how it got that way, isn't this an indication that abrt's 'this report is incomplete' check needs to be better?

Comment 7 Jiri Moskovcak 2013-08-21 11:03:56 UTC
The problem described in comment #1 is caused by missing type element in the problem directory, I just sent a patch which makes abrt to detect it and prevent user from running the report event on such problem data.

Comment 8 Jiri Moskovcak 2013-08-30 07:18:34 UTC
fixed in git

Author: Jiri Moskovcak <jmoskovc>
Date:   Wed Aug 21 16:13:40 2013 +0200

    ignore directories without type element - rhbz#958968
    
    Signed-off-by: Jiri Moskovcak <jmoskovc>
    Signed-off-by: Jakub Filak <jfilak>

Comment 9 Fedora Update System 2013-09-13 13:10:22 UTC
gnome-abrt-0.3.1-1.fc19,abrt-2.1.7-1.fc19,libreport-2.1.7-1.fc19,satyr-0.9-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/gnome-abrt-0.3.1-1.fc19,abrt-2.1.7-1.fc19,libreport-2.1.7-1.fc19,satyr-0.9-1.fc19

Comment 10 Fedora Update System 2013-09-14 02:40:08 UTC
Package gnome-abrt-0.3.1-1.fc19, abrt-2.1.7-1.fc19, libreport-2.1.7-1.fc19, satyr-0.9-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-abrt-0.3.1-1.fc19 abrt-2.1.7-1.fc19 libreport-2.1.7-1.fc19 satyr-0.9-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16707/gnome-abrt-0.3.1-1.fc19,abrt-2.1.7-1.fc19,libreport-2.1.7-1.fc19,satyr-0.9-1.fc19
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2013-09-15 00:55:22 UTC
gnome-abrt-0.3.1-1.fc19, abrt-2.1.7-1.fc19, libreport-2.1.7-1.fc19, satyr-0.9-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.