Bug 958968 - Trying to report older crashes results in "Error: no processing is specified for event 'report-cli'" with libreport 2.1.3 / 2.1.4
Summary: Trying to report older crashes results in "Error: no processing is specified ...
Alias: None
Product: Fedora
Classification: Fedora
Component: libreport
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-05-02 19:57 UTC by Adam Williamson
Modified: 2015-02-01 22:55 UTC (History)
9 users (show)

Fixed In Version: gnome-abrt-0.3.1-1.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-15 00:55:22 UTC
Type: Bug

Attachments (Terms of Use)
offending oops (740 bytes, application/octet-stream)
2013-05-03 17:16 UTC, Adam Williamson
no flags Details

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@redhat.com>
Date:   Wed Aug 21 16:13:40 2013 +0200

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

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.

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

Note You need to log in before you can comment on or make changes to this bug.