This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 528395 - kerneloopses no longer easily reported
kerneloopses no longer easily reported
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Moskovcak
Fedora Extras Quality Assurance
:
: 525868 (view as bug list)
Depends On:
Blocks: F12Target
  Show dependency treegraph
 
Reported: 2009-10-11 19:02 EDT by Mads Kiilerich
Modified: 2015-02-01 17:49 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 10:26:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Mads Kiilerich 2009-10-11 19:02:22 EDT
Description of problem:

It seems like abrt has taken over the role of the old kerneloops reporter?

Kernel oopses are not visible in abrt-gui for ordinary users, so there is no longer a simple way to report oopses. That is a regression.

There entries in /var/log/messages gives no hint that the gui tool should be run as root(!): 
Oct 11 23:31:07 localhost abrt: Kerneloops: Reported 1 kernel oopses to Abrt
Oct 11 23:31:07 localhost abrtd: Directory 'kerneloops-1255296667-1' creation detected

I assume that polkit should allow local users to report oopses (and crashes in daemons etc).


Version-Release number of selected component (if applicable):
abrt-0.0.9-2.fc12.i686
Comment 1 Andrew McNabb 2009-10-23 18:21:03 EDT
Yeah.  It used to be easy to configure kerneloopses to automatically report without any interaction from the user.  Is this possible anymore?
Comment 2 Gene Czarcinski 2009-10-25 15:59:16 EDT
+1

Not obvious at all that you need to run abrt-gui as root to see some of the problems.
Comment 3 Christopher Beland 2009-10-27 11:18:10 EDT
*** Bug 525868 has been marked as a duplicate of this bug. ***
Comment 4 Zack Cerza 2009-10-27 11:21:01 EDT
Whoa. It doesn't even report them automatically? Is this true?
Comment 5 Zack Cerza 2009-10-27 11:24:46 EDT
FWIW, abrt-gui is very broken when run as root. I'm unable to report any of the crashes I see when I run it as root - none of which I even knew about since they were hidden from the normal user view...
Comment 6 Nicolas Mailhot 2009-10-27 11:40:58 EDT
It is very unfortunate this reporting was broken before the beta, and I believe that if it is not restored soonish we'll pay the price in kernel stability at release time

This could qualify as release blocker IMHO
Comment 7 Mads Kiilerich 2009-10-27 12:16:29 EDT
I have been testing/beating/bugreporting a lot on abrt. It is a young project and has the potential to become a good and central hub in Fedora. 

But I think it is fair to say that it just isn't production quality yet. It is a fine and usable alpha release. It is not just a single bug; abrt is lacking in many areas, both regarding usability, functionality and stability. It obviously haven't been widely used, loved and polished yet. It is definitely not as mature as the old kerneloops reporter and similar tools like bugbuddy and the selinux reporter and similar tools used by other distributions.

I don't think abrt is ready for a role where it _can_ be a release blocker. It should not be the default kerneloops reporter yet, and it probably shouldn't be installed by default yet.
Comment 8 Andrew McNabb 2009-10-27 12:56:51 EDT
(In reply to comment #7)
> 
> I don't think abrt is ready for a role where it _can_ be a release blocker. It
> should not be the default kerneloops reporter yet, and it probably shouldn't be
> installed by default yet.  

If people get a bad impression from abrt now, it will be hard to rebuild its reputation later.  And it would be a step back to have abrt replace the kerneloops daemon before it has replicated all of its functionality and configurability.

I think that abrt has a lot of potential, but it should really wait until Fedora 13.
Comment 9 Jiri Moskovcak 2009-10-27 13:00:49 EDT
It's not that big deal guys, we can easily remove the kerneloops plugin from abrt and use the old kerneloops in F12 and let abrt handle only the python and C/C++ stuff. What do you think?

Jirka
Comment 10 Andrew McNabb 2009-10-27 13:20:25 EDT
(In reply to comment #9)
> It's not that big deal guys, we can easily remove the kerneloops plugin from
> abrt and use the old kerneloops in F12 and let abrt handle only the python and
> C/C++ stuff. What do you think?

That would solve the current bug, so I think it's a first step.  However, it wouldn't address any of the other UI and stability issues.  I'm sure these will get fixed, and abrt will be great, but I'm skeptical that this will happen before the Fedora 12 release.
Comment 11 Nicolas Mailhot 2009-10-27 14:03:07 EDT
The priority is to restore previously working functionality Fedora depended on (ie kerneloops). I don't think it's too bad if abrt is a little raw for other stuff we had no tool for before
Comment 12 Gene Czarcinski 2009-10-27 14:23:28 EDT
+1 ... in F12, use kerneloops for kernel problems but leave abrt in and installed by default.

I believe that some thought should be given to what functionality is missing and/or does not work right and then prioritize the problems ...

Yes, some things may be easy to fix but does the problem matter much.  On the other hand, some problems may be really hard to fix (require lots of effort) but be really important.

While abrt can currently handle user-mode application failures, there are problems with things which are root mode such as the kernel (but not just the kernel) ... e.g., I am having a problem with the plymouth daemon.
Comment 13 Jiri Moskovcak 2009-10-28 07:54:53 EDT
I already fixed some bugs related to reporting failures from under root and we're going to release and updated version which should also allow non-root users to see and report kerneloopses (and also remove the oops plugin from abrt default installation). As for other ideas and improvements please use crash-catcher@lists.fedorahosted.org so other people interested in ABRT will notice it.

Thank you,
Jirka
Comment 14 Andrew McNabb 2009-10-28 10:54:33 EDT
Is there anything like "allow-submit = yes" (a configuration option in /etc/kerneloops.conf)?  Setting this allows me to send kerneloops reports without any interaction from the users.  I would hate to have to run a GUI tool as root on each of 50 machines just to submit reports, not to mention that many machines don't even have "users".  Thanks.
Comment 15 Jiri Moskovcak 2009-10-30 08:24:21 EDT
In the latest git version there is no need to run the GUI as root to see the oopses, but even having to run the gui is not a solution for a server. That's why we have abrt-cli, which can be used in scripts and you can use cron to make abrt report new oopses when you want. I don't like the idea of reporting it automatically when it happens, as the computer might be loaded with some other work, so the solution with cron seems better to me. Or if you don't like the cli, you can write your own script talking to abrt daemon over dbus which will suit your needs.

Jirka
Comment 16 Nicolas Mailhot 2009-10-30 08:54:03 EDT
Jirka,

You are free to implement it however you want, but it must work by default with no GUI/CLI or any other user intervention. If you think a cron is the best solution, ship the cron file in your package and make sure it works for selinux.

The previous kerneloopser worked fine; it would be nice if abrt allowed more flexibility, but if abrt means something that just worked is now unreliable and requiring manual management, it is a regression.
Comment 17 Jiri Moskovcak 2009-10-30 09:07:14 EDT
I agree it's a regression, that's why I removed the kerneloops plugin from the default ABRT installation, comment #15 is just hint or workaround how to make abrt work as old kerneloops if someone desperately wants to use ABRT instead of kerneloops.

Jirka
Comment 18 Andrew McNabb 2009-11-02 16:54:43 EST
I just installed a fresh Rawhide machine (with abrt abrt-0.0.10-1.fc12.x86_64), but the abrt Kerneloops plugins were still loaded, and there is no kerneloops package available for installation.  Comment #17 seemed to say that the abrt kerneloops plugin was being removed and the kerneloops package was being reintroduced.  Is that not the case?
Comment 19 Chuck Ebbert 2009-11-02 18:37:42 EST
kerneloops has been completely removed from F-12 and is marked as a dead package in devel.
Comment 20 Andrew McNabb 2009-11-02 18:46:48 EST
Ouch.  I hope no one needs kerneloops reports. :(
Comment 21 Anton Arapov 2009-11-03 02:49:01 EST
  Jiri, I can't believe you switched off kerneloops plugin... Is it so difficult to introduce the automagically and blindly report the kernel oopses to kerneloops.org?
  afaik, this is the field of abrt, to make this happen, not the reporting plugin itself... it's a matter of configuration of the plugin, right?

  /me hopes to see plugin enabled and 'report automatically' feature as soon as possible. :)
Comment 22 Jiri Moskovcak 2009-11-03 04:58:25 EST
Anton,
I did this as it was the fastest solution which we can provide and we needed to fix this before F12 RC. We'll fix this ASAP, but we couldn't afford to push unstable daemon+plugins to F12.
Comment 23 Jiri Moskovcak 2009-11-03 05:11:16 EST
But if the old kerneloops are not in F12, I'm going to re-enable it in ABRT, as the only feature missing is automatic reporting of oopses (yes, the non-root users can report the oopses now) and the automatic reporting will be the part of next update (in a week).

Jirka
Comment 24 Mads Kiilerich 2009-11-03 05:11:52 EST
Re comment #21:
For privacy reasoons it is not acceptable that kerneloopses are reported silently. A sufficiently authorized user must authorize it - and that user can then authorize abrt to report it silently. I think it would be nice if abrt used PolicyKit for such policy handling.

(There will also be a need for reporting oopses from other system processes and daemons. Perhaps abrt-gui should notify un-authorized users that "something which might be interesting" can be seen, but only allow the user to see it after sufficiently authentication.)

(For privacy reasons it is also very important that submitters can review _exactly_ what is reported so they can make sure that nothing confidential is submitted.)
Comment 25 Jens Knutson 2009-11-03 07:22:11 EST
(In reply to comment #24)
> Re comment #21:
> For privacy reasoons it is not acceptable that kerneloopses are reported
> silently.

What kind of confidential/private information is going to be in a /kernel oops/?  Is the type of video card one uses considered "confidential"?
Comment 26 Mads Kiilerich 2009-11-03 07:45:38 EST
Re comment 25:

I don't know how much a kerneloops can reveal, but I don't think that matters. Users should be able to trust that a Fedora system _never_ calls home silently. Fedora should not decide if users should trust that kerneloops doesn't reveal IP addresses.

Some users might have a local policy that _nothing_ may be leaked. Some examples could be MS test labs, NVidia next-generation driver development department, NSA, google.

(AFAIK yum repos and ntp servers are the most obvious exceptions to this in Fedora, and AFAIK they take care to reveal as little as possible to the server)

(Obviously this is _my_ opinion. Others with authority might have a different opinion.)
Comment 27 Michal Nowak 2009-11-03 09:03:20 EST
Mads: you are mixing two things - the accessibility of OOPS message and automatic sending of that information. The former is not going to be affected by ABRT's existence (you can see OOPS message in dmesg as well as in abrt-gui), the letter is not implemented yet (and will auto-send OOPS only on user's demand).
Comment 28 Mads Kiilerich 2009-11-03 09:34:42 EST
Re Comment #27:
I might have misunderstood it, but in comment #24 I was responding to comment #21 which AFAICS mentioned "blindly report" and "report automatically" as a solution. If that was said under the assumption that an authorized user had told it so then we all agree ;-)
Comment 29 Zack Cerza 2009-11-03 10:08:54 EST
(In reply to comment #23)
> But if the old kerneloops are not in F12, I'm going to re-enable it in ABRT, as
> the only feature missing is automatic reporting of oopses (yes, the non-root
> users can report the oopses now) and the automatic reporting will be the part
> of next update (in a week).
> 
> Jirka  

In abrt-0.0.10-1.fc12.x86_64, I can't see oopses as non-root (and I can't report them as root from within my non-root session).
Comment 30 Nikola Pajkovsky 2009-11-03 10:35:26 EST
It will be in new release. Coming soon.
Comment 31 Zack Cerza 2009-11-03 11:56:28 EST
(In reply to comment #30)
> It will be in new release. Coming soon.  

Okay. Thanks!
Comment 32 Jiri Moskovcak 2009-11-04 10:06:11 EST
#29
Should be fixed in abrt 0.0.11, you can find the build in koji, but it should hit the rpeository soon.
Comment 33 Denys Vlasenko 2009-11-30 04:46:02 EST
1.0.0 F12 in koji:

http://koji.fedoraproject.org/koji/buildinfo?buildID=142493
Comment 34 Mads Kiilerich 2009-11-30 06:06:46 EST
Yes, but it is my experience that sometimes I can see oopses as an ordinary user, but not always. How is it supposed to work? Who can see what when and how is it controlled?

And still I see:

https://fedorahosted.org/abrt/ticket/102 - it catches something which definitely isn't an oops. Is that what it is uploading?

https://fedorahosted.org/abrt/ticket/96 - there is no way (AFAICS) to find out what has been uploaded.
Comment 35 Denys Vlasenko 2009-11-30 07:24:48 EST
(In reply to comment #34)
> Yes, but it is my experience that sometimes I can see oopses as an ordinary
> user, but not always. How is it supposed to work? Who can see what when and how
> is it controlled?

It is controlled in /etc/abrt/plugins/Kerneloops.conf with InformAllUsers option.
In default installation it is set to InformAllUsers = yes.
 
> And still I see:
> 
> https://fedorahosted.org/abrt/ticket/102 - it catches something which
> definitely isn't an oops. Is that what it is uploading?

This is fixed in 1.0.0

> https://fedorahosted.org/abrt/ticket/96 - there is no way (AFAICS) to find out
> what has been uploaded.  

Will look into this one.
Comment 36 Nikola Pajkovsky 2009-11-30 07:35:01 EST
> It is controlled in /etc/abrt/plugins/Kerneloops.conf with InformAllUsers
> option.
> In default installation it is set to InformAllUsers = yes.

And default option is also AutoReportUIDs = root that means kerneloops is automatically reported.
Comment 37 Mads Kiilerich 2009-12-04 15:51:04 EST
Re #36:

Nikola, what do "automatically reported" mean?

Where are these options documented?
Comment 38 Nikola Pajkovsky 2009-12-05 09:39:28 EST
(In reply to comment #37)
> Re #36:
> 
> Nikola, what do "automatically reported" mean?
> 
When kerneloops is detected in /var/log/messages and in kerneloops.conf is set option AutoReportUIDs = root then we will send report to kerneloops.org without any user action 

> Where are these options documented?  
For now we have kerneloops as plugin, but we have a plan to make kerneloops as daemon. For now, nowhere. Thx for info I will add this option into documentation.
Comment 39 Mads Kiilerich 2009-12-13 17:29:48 EST
I should perhaps wait for the explanation in the upcoming documentation of these options, but:

As I understand it from what you are saying here then I don't think AutoReportUIDs=root is an acceptable default. But I don't understand why "UID" and "root" is used for something that sounds like a boolean.

The name "InformAllUsers" also confuses me. I am looking forward to the description in the documentation.
Comment 40 Denys Vlasenko 2009-12-15 06:19:48 EST
I propose the following default Kerneloops.conf:


# Do we want kernel oopses to be visible to any user?
# Set to "yes" for compatibility with kerneloops.org tool.
InformAllUsers = yes

# Automatically perform reporting.
# With default abrt.conf, it invokes KerneloopsReporter
# and thus reports oops to kerneloops.org.
# ("root" because all oopses are filed by abrt with user "root")
AutoReportUIDs = root

# Kerneloops Scanner configuration
##################################
SysLogFile = /var/log/messages

# KerneloopsReporter configuration
##################################
SubmitURL = http://submit.kerneloops.org/submitoops.php
Comment 41 Mads Kiilerich 2009-12-15 08:47:31 EST
Is "visible" and "inform" only about showing kerneloopses? Or is it also about being able to report them?

IMHO it looks like AutoReportUIDs solves a different problem and isn't a good solution to this problem.

But this all means that kerneloopses by default are reported silently to a non-Fedora site and we can't tell where the user can see the report? IMHO that isn't good enough. To rephrase my understanding of the original problem: By default ordinary users should be notified that there is a oops, but only root should be able to see and report it, and reporting must be explicitly approved - exactly like package updates are handled.


I suggest something like:

# Notify all users when a kerneloops is detected and allow them
# to see and report it if they can provide root credentials?
NotifyUsers = yes

# Report kerneloopses automatically without explicit approval?
AutoReport = no

# The KerneloopsReporter monitors this file for new kerneloopses
# See the abrt-KerneloopsScanner man page.
SysLogFile = /var/log/messages

# KerneloopsReporter reports kerneloopses at this URL
# See the abrt-KerneloopsReporter man page.
SubmitURL = http://submit.kerneloops.org/submitoops.php
Comment 42 Jiri Moskovcak 2009-12-15 09:32:49 EST
(In reply to comment #41)
> Is "visible" and "inform" only about showing kerneloopses? Or is it also about
> being able to report them?
> 

- if user sees it, he can report it

> IMHO it looks like AutoReportUIDs solves a different problem and isn't a good
> solution to this problem.
> 
> But this all means that kerneloopses by default are reported silently to a
> non-Fedora site and we can't tell where the user can see the report? IMHO that
> isn't good enough.

- this is exactly the same behavior as the old kerneloops

> To rephrase my understanding of the original problem: By
> default ordinary users should be notified that there is a oops, but only root
> should be able to see and report it, and reporting must be explicitly approved
> - exactly like package updates are handled.
>

- but we're trying to act exactly as the old kerneloops as this BZ requires
Comment 43 Mads Kiilerich 2009-12-15 12:31:39 EST
>> But this all means that kerneloopses by default are reported silently to a
>> non-Fedora site and we can't tell where the user can see the report? IMHO that
>> isn't good enough.
> 
> - this is exactly the same behavior as the old kerneloops

http://git.infradead.org/kerneloops.git/blob/HEAD:/kerneloops.conf says:
Default is "ask" which uses a UI application t ask the user for permission

So no, silent reporting by default is not the same behavior as the old kerneloops, AFAICS. The old kerneloops did however notificaty users that "something happended", and it trusted some users to report it.

>> To rephrase my understanding of the original problem: By
>> default ordinary users should be notified that there is a oops, but only root
>> should be able to see and report it, and reporting must be explicitly approved
>> - exactly like package updates are handled.
> 
> - but we're trying to act exactly as the old kerneloops as this BZ requires

Ok.

This issue is a request for removing a regression. That shouldn't prevent you from solving the minor problems of the old kerneloops.

PackageKit is a very good model for how it can be done even better than the kerneloops. There are good reasons why PackageKit does what it does, and these reasons could also apply to abrt.
Comment 44 Mads Kiilerich 2010-01-28 10:05:11 EST
The "Privilege escalation policy" discussed on http://lists.fedoraproject.org/pipermail/test/2010-January/088177.html seems relevant for what we are discussing here.

I will Cc Adam Williamson - I hope that is Ok.

The policy draft mentions
* Read from system logs containing any information about user activities
I think that covers what abrt does - including kerneloops and crashes in system daemons.

I think that something like "change settings for automatic reporting of potentially privacy-sensitive information" should be added. (That might however be a overly complex wording because all automatic reporting is potentially privacy critical ...)
Comment 45 Adam Williamson 2010-01-28 14:40:51 EST
as the privilege escalation policy draft is currently worded, yes, it would be wrong for abrt to extract information from logs the unprivileged user is intentionally denied access to (such as /var/log/messages) and let the user see/submit them without authentication. Of course, the draft is very very much a draft at present, has not been accepted at any official level, and has absolutely no force.
Comment 46 Bug Zapper 2010-03-15 08:56:16 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 47 Bug Zapper 2011-06-02 13:37:09 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 48 Bug Zapper 2011-06-27 10:26:43 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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