New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capture unpackaged crashers by default #891

Closed
hadess opened this Issue Dec 16, 2014 · 8 comments

Comments

Projects
None yet
4 participants
@hadess
Contributor

hadess commented Dec 16, 2014

Unpackaged or unknown to Fedora. This would allow users to gather debugging information for system problems with third-party drivers or applications, and make it easier to discard data about those crashers without dropping to the command-line.

@jfilak

This comment has been minimized.

Show comment
Hide comment
@jfilak

jfilak Feb 2, 2015

Member

@hadess I'm not sure what you mean by the last sentence. I guess you want ABRT to delete a journald message that was used to create an abrt problem, right? So gnome-abrt should become an unofficial GUI for coredumpctl, right?

Member

jfilak commented Feb 2, 2015

@hadess I'm not sure what you mean by the last sentence. I guess you want ABRT to delete a journald message that was used to create an abrt problem, right? So gnome-abrt should become an unofficial GUI for coredumpctl, right?

@hadess

This comment has been minimized.

Show comment
Hide comment
@hadess

hadess Feb 4, 2015

Contributor

I'd want to remove the journald entries if the abrt entry was removed as well. For example, being able to remove development crashers that I already handled locally.

But the main goal would be for unpackaged crashers to appear in the UI, so it was possible to analyse them and identify them, even for third-party applications and utilities.

Contributor

hadess commented Feb 4, 2015

I'd want to remove the journald entries if the abrt entry was removed as well. For example, being able to remove development crashers that I already handled locally.

But the main goal would be for unpackaged crashers to appear in the UI, so it was possible to analyse them and identify them, even for third-party applications and utilities.

@jfilak

This comment has been minimized.

Show comment
Hide comment
@jfilak

jfilak Feb 4, 2015

Member

OK. I had to ask because such a thing is not possible now. ABRT doesn't execute any hook when deleting a problem, it just remove the related problem directory.

Member

jfilak commented Feb 4, 2015

OK. I had to ask because such a thing is not possible now. ABRT doesn't execute any hook when deleting a problem, it just remove the related problem directory.

@hadess

This comment has been minimized.

Show comment
Hide comment
@hadess

hadess Feb 4, 2015

Contributor

Being able to show it would be a first step, being able to delete it from the list (eg. from the view) would the 2nd one. I don't even know if one can remove core dumps from journald right now (we might not be able to, as it would modify the integrity of previous logs, break audit).

Contributor

hadess commented Feb 4, 2015

Being able to show it would be a first step, being able to delete it from the list (eg. from the view) would the 2nd one. I don't even know if one can remove core dumps from journald right now (we might not be able to, as it would modify the integrity of previous logs, break audit).

@jfilak

This comment has been minimized.

Show comment
Hide comment
@jfilak

jfilak Feb 4, 2015

Member

You can at least delete a coredump related to a particular journal message because systemd-coredump stores coredump files outside the journal.

Member

jfilak commented Feb 4, 2015

You can at least delete a coredump related to a particular journal message because systemd-coredump stores coredump files outside the journal.

@jfilak jfilak closed this in c5ea96e Feb 5, 2015

@mtoman

This comment has been minimized.

Show comment
Hide comment
@mtoman

mtoman Feb 5, 2015

Member

Even though the change is already implemented I need to say this is a bad idea. I can not see a single benefit (the suggested gui-frontend-to-coredumpctl is absolutely out of scope of the project). On the other hand this will create tons of unreportable entries in ABRT GUI that are only going to confuse users.

Member

mtoman commented Feb 5, 2015

Even though the change is already implemented I need to say this is a bad idea. I can not see a single benefit (the suggested gui-frontend-to-coredumpctl is absolutely out of scope of the project). On the other hand this will create tons of unreportable entries in ABRT GUI that are only going to confuse users.

@mbrysa

This comment has been minimized.

Show comment
Hide comment
@mbrysa

mbrysa Feb 5, 2015

Contributor

Automated Bug Reporting Tool - who are you going to report crashes of third-party apps to?
I'm for reverting this.

Contributor

mbrysa commented Feb 5, 2015

Automated Bug Reporting Tool - who are you going to report crashes of third-party apps to?
I'm for reverting this.

@hadess

This comment has been minimized.

Show comment
Hide comment
@hadess

hadess Feb 5, 2015

Contributor

If the goal is not to help developers and QE, then we can rip out half of gnome-abrt. We even made design decisions based on the fact that it wasn't only a bug reporting tool for end users.

Contributor

hadess commented Feb 5, 2015

If the goal is not to help developers and QE, then we can rip out half of gnome-abrt. We even made design decisions based on the fact that it wasn't only a bug reporting tool for end users.

jfilak pushed a commit that referenced this issue Apr 8, 2015

Jakub Filak
testsuite: fix dbus-configuration test
The test was expecting ProcessUnpackaged to be set to 'False' by default
but this option has been changed to 'True' by default in
commit c5ea96e

Related to #891

Signed-off-by: Jakub Filak <jfilak@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment