Main Inclusion Request for kerneloops

Before this MIR continues, the daemon should be made to run as a non-root user. There doesn't appear to be any reason for this (kernel logs available via group adm, dbus can be done in other ways). Having the root user performing outbound network communication is cause for concern.

I have attached a kernel module (out of tree build) that can do oops, bug, warn, and panic on demand. It is not
part of the mainline nor is it in a kernel package at this point, mainly because it should be for internal testing _only_.
README and build script included.

In addition, I noticed today that for some reason, key portions of the oops/bug messages are not sent to
/var/log/messages. They are placed in /var/log/kern.log however. The impact of this is that the log scanner cannot
find the start of the sequence. Since the use of "/var/log/messages", either the kerneloops code has to be changed
by adding an additional conf file parameter or /etc/syslog.conf has to be changed to send all kernel messages to
/var/log/messages rather than the select set it does now:

*.=info;*.=notice;*.=warning;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none -/var/log/messages

It would be a good idea to change the url to point elsewhere than kerneloops.org when testing...

I've uploaded a new kerneloops that uses the "kernoops" user instead of root, and fixes a bunch of things in the packaging. Please test -- I am able to get neither the old kerneloops nor this new one to actually report anything for me.

Package has been uploaded to main.

For the record, I applied a simple DKMSification to kernel-crasher and uploaded it to my PPA, for easy testing: https://launchpad.net/~pitti/+archive/ppa/

With kernel-crasher I triggered a kernel OOPS, logged out, back in, and got a dialog box

  Your system had a kernel crash.

          [ Cancel ] [OK]

I pressed "OK", and nothing happened. Kees, can you please check your latest modifications to kerneloops?

How should it behave?

On Thu, Feb 19, 2009 at 08:35:19PM -0000, Martin Pitt wrote:
> I pressed "OK", and nothing happened. Kees, can you please check your
> latest modifications to kerneloops?

The main change I made was running kerneloops as non-root (see init script
and .dbus file). I was unable to test it because kerneloops never did
anything for me (before or after my modifications).

I would like to see kerneloops running as kernoops:adm rather than
root:root. I'm about to be on vacation for a week, so feel free to back
out anything that might be causing this.

Also, since that test crash kerneloops repeats the same dialog box again and again with every login, it doesn't seem to remove whatever cached information it writes about the crash report. I never got an apport .crash file for oopses either, I thought it was supposed to write those now?

Should this package be seeded in ubuntu-standard? Its has no other dependency, so it has already migrated from main back to universe.

I've added kerneloops to the standard seed; the next rebuild of ubuntu-meta will include this.

revno: 1303
committer: Colin Watson <email address hidden>
branch nick: platform.jaunty
timestamp: Thu 2009-02-26 22:42:13 +0000
message:
  add kerneloops to standard (LP: #327819)

(Of course the ubuntu-mir team will need to finish with this before it takes effect.)

Please note that comment 4 was misleading, you can't "upload to main". This package has always been in universe since the MIR hasn't been approved yet. Blockers that I see with the current package:

 - Does not ever forget a crash, but reminds me about one at each and every desktop login. I had to purge the package to get rid of it.

 - The UI is utterly confusing. It opens a dialog box at session start saying

     Your system had a kernel failure.

       [ OK ] [Cancel]

   Regardless of which button I press, the dialog just goes away and nothing happens. I don't know whether it sends the report to kerneloops.org (how can I tell), but if so, it should point out that it's going to send some information to the network, and give some confirmation once that's done. E. g. "OK" should then be called "Send report to kerneloops.org ...".

The apport integration which it already attempts to do doesn't work, but that's rather a bug, not a blocker for MIR.

Setting back to incomplete, since this needs work on the package.

The UI problem is the fault of notify-osd (bug 340773). The never-forgets issue is related to the UI not functioning any more (it would normally reply to the kerneloops daemon to "release" the crash), and therefore never calls apport either.

I don't think the never-forgets issue is related to the UI. Even with the fixed dialog from bug 344377, it still reports the same event every time it starts up.

I've filed bug 345483 to track one variety of never-forgetting.

I don't think there is any issue which should block the MIR at this point, but I also think it's probably too late in Jaunty to seriously consider adding this by default. There are likely lots more problems that we would run into if we unleashed this on everyone.

This package will stay in universe for Jaunty. For Karmic the package will be managed by the Foundations team specifically Keybuk. The plan is to have this in main for Karmic. Setting the owner to Scott Jame Remnant, Milestone to Ubuntu:Later, Status: Triaged.

If this daemon continues to run as non-root, it is approved for main.

> If this daemon continues to run as non-root, it is approved for main.

That is still the case, and I think I have fixed some of the other concerns
raised in this bug, or have them on my radar.

I'm going to seed this in standard based on that comment, if someone
from ubuntu-mir wants to re-review please speak up.

Thanks,

James

I think this is in main, fix releasing.