Bug 859724 - ABRT doesn't get launched on crashes
Summary: ABRT doesn't get launched on crashes
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 18
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: abrt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-23 14:49 UTC by Zeeshan Ali
Modified: 2016-09-20 01:41 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-02-05 23:22:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zeeshan Ali 2012-09-23 14:49:40 UTC
Description of problem:

When an application crashes (e.g epiphany currently crashes for me on loading gmail.com), I don't get the notification about it. Seems the crash is not even detected since if i launch ABRT manually, the crashes are not listed in the UI.

Version-Release number of selected component (if applicable): 2.0.12-1.fc18

How reproducible: always

Steps to Reproduce:
1. Crash an application using `kill -SEGV PID_OF_APP`
  
Actual results: The application in question crashes but user gets no notification for sending the crash report.

Expected results: A notification about the crash should pop-up.

Comment 1 Jiri Moskovcak 2012-09-24 06:50:18 UTC
I believe that this might be connected to recent change in the config file /etc/abrt/abrt-action-save-package-data.conf where package signature has been checking has been turned on. You can try to find this line and change it to off:

OpenGPGCheck = yes


Please check if the package installed on your system are signed:

$ rpm -qi <PACKAGE> | grep "Signature"

Comment 2 Zeeshan Ali 2012-09-24 15:58:46 UTC
(In reply to comment #1)
> I believe that this might be connected to recent change in the config file
> /etc/abrt/abrt-action-save-package-data.conf where package signature has
> been checking has been turned on. You can try to find this line and change
> it to off:
> 
> OpenGPGCheck = yes

I changed that to 'no' but it didn't help at all. I guess I have to relaunch the abrt daemons somehow? I did a `killall -HUP` to them but that just killed them. I manually launched them but that didn't help either. Besides the package in question is signed (see below).
 
> 
> Please check if the package installed on your system are signed:
> 
> $ rpm -qi <PACKAGE> | grep "Signature"

$ LC_TIME=en_US.utf8 rpm -qi epiphany | grep "Signature
Signature   : RSA/SHA256, Thu 20 Sep 2012 04:27:17 AM EEST, Key ID ff01125cde7f38bd

Comment 3 Jiri Moskovcak 2012-09-25 07:10:58 UTC
Please provide output of the following commands:

$ cat /proc/sys/kernel/core_pattern 

$ sleep 100 &
$ kill -s SEGV $!
$ grep "abrt" /var/log/messages

Comment 4 Zeeshan Ali 2012-09-25 13:52:58 UTC
(In reply to comment #3)
> Please provide output of the following commands:
> 
> $ cat /proc/sys/kernel/core_pattern 

core

> $ sleep 100 &
> $ kill -s SEGV $!
> $ grep "abrt" /var/log/messages

Thats a huge output but I think you wanted to see the tail:

Sep 25 16:41:28 localhost yum[1107]: Updated: abrt-libs-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-addon-kerneloops-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-addon-vmcore-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-plugin-bodhi-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-retrace-client-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-addon-ccpp-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-addon-python-2.0.13-1.fc18.x86_64
Sep 25 16:41:29 localhost yum[1107]: Updated: abrt-dbus-2.0.13-1.fc18.x86_64
Sep 25 16:41:30 localhost yum[1107]: Updated: abrt-addon-xorg-2.0.13-1.fc18.x86_64
Sep 25 16:41:30 localhost yum[1107]: Updated: abrt-gui-2.0.13-1.fc18.x86_64
Sep 25 16:42:36 localhost yum[1107]: Updated: abrt-desktop-2.0.13-1.fc18.x86_64
Sep 25 16:43:29 localhost systemd[1]: Job abrt-vmcore.service/start failed with result 'dependency'.

Comment 5 Jiri Moskovcak 2012-09-25 14:25:55 UTC
Seems like abrtd and abrt-ccpp service is not started properly, please try to restart these services or restart the whole machine if possible.

Comment 6 Zeeshan Ali 2012-09-25 17:04:58 UTC
(In reply to comment #5)
> Seems like abrtd and abrt-ccpp service is not started properly, please try
> to restart these services or restart the whole machine if possible.

Rebooted the system and repeated those commands. Now i see these lines appended to /var/log/messages:

Sep 25 17:39:17 localhost abrtd: Can't lock file '/var/run/abrt/abrtd.pid': Resource temporarily unavailable
Sep 25 17:39:17 localhost abrtd: Error while initializing daemon
Sep 25 17:39:17 localhost abrtd: Exiting
Sep 25 17:39:17 localhost systemd[1]: abrtd.service: main process exited, code=exited, status=1
Sep 25 17:39:17 localhost systemd[1]: Unit abrtd.service entered failed state.
Sep 25 17:39:36 localhost systemd[1]: Job abrt-ccpp.service/start failed with result 'dependency'.
Sep 25 19:37:22 localhost abrtd: Init complete, entering main loop

Comment 7 Jiri Moskovcak 2012-09-26 07:12:48 UTC
Seems like a stalled pid file, please post the output of these commands:

$ cat /var/run/abrt/abrtd.pid
$ cat /proc/${`cat /var/run/abrt/abrtd.pid`}/cmdline

Comment 8 Zeeshan Ali 2012-09-26 12:12:32 UTC
(In reply to comment #7)
> Seems like a stalled pid file, please post the output of these commands:
> 
> $ cat /var/run/abrt/abrtd.pid
847
> $ cat /proc/${`cat /var/run/abrt/abrtd.pid`}/cmdline

$ cat /var/run/abrt/abrtd.pid
847
$ cat /proc/847/cmdline
/usr/sbin/abrtd-d-s

Comment 9 Jiri Moskovcak 2012-09-26 14:03:15 UTC
According to comment#8 the abrtd is running, so just running:

$ service abrt-ccpp start

should fix it.

Comment 10 Zeeshan Ali 2012-09-27 00:48:27 UTC
(In reply to comment #9)
> According to comment#8 the abrtd is running, so just running:
> 
> $ service abrt-ccpp start
> 
> should fix it.

Yeah, that fixed it. Shouldn't it have started on its own?

Comment 11 Jiri Moskovcak 2012-09-27 07:57:47 UTC
It should and it's enabled to start on boot when you install the package but not if it's updated. Any chance you were updating to f18 from some older Fedora?

Anyway, this command will make it start on boot:

$ /bin/systemctl enable abrt-ccpp.service

Comment 12 Zeeshan Ali 2012-09-27 12:29:04 UTC
(In reply to comment #11)
> It should and it's enabled to start on boot when you install the package but
> not if it's updated.

Why not?

> Any chance you were updating to f18 from some older
> Fedora?

Yes, thats what I did exactly: F17 -> F18.

Comment 13 Jiri Moskovcak 2012-09-27 12:49:25 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > It should and it's enabled to start on boot when you install the package but
> > not if it's updated.
> 
> Why not?
> 

- I think I wasn't clear here - on update it's left as it was, so if it was disabled, it stays disabled, if it was enabled, it stays enabled...
- on install it is just unconditionally enabled

> > Any chance you were updating to f18 from some older
> > Fedora?
> 
> Yes, thats what I did exactly: F17 -> F18.
- so is there any chance you had abrt-ccpp disabled on F17? Or there might be a bug in the rpm scriptlet, but it's been working without change for some time ..

Comment 14 Zeeshan Ali 2012-09-27 13:53:54 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > It should and it's enabled to start on boot when you install the package but
> > > not if it's updated.
> > 
> > Why not?
> > 
> 
> - I think I wasn't clear here - on update it's left as it was, so if it was
> disabled, it stays disabled, if it was enabled, it stays enabled...
> - on install it is just unconditionally enabled
> 
> > > Any chance you were updating to f18 from some older
> > > Fedora?
> > 
> > Yes, thats what I did exactly: F17 -> F18.
> - so is there any chance you had abrt-ccpp disabled on F17?

I have submitted several reports from F17 with the help of ABRT and I don't recall disabling it so its very unlikely but still possible.

> Or there might
> be a bug in the rpm scriptlet, but it's been working without change for some
> time ..

Or that. :) I guess you can mark this as INVALID if noone else has reported the same.

Comment 15 Fedora Update System 2012-10-05 10:46:56 UTC
abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17

Comment 16 Fedora Update System 2012-10-06 03:47:26 UTC
Package abrt-2.0.14-1.fc17, libreport-2.0.15-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.14-1.fc17 libreport-2.0.15-1.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15498/abrt-2.0.14-1.fc17,libreport-2.0.15-1.fc17
then log in and leave karma (feedback).

Comment 17 Fedora Update System 2012-10-08 02:25:12 UTC
Package libreport-2.0.15-1.fc17, abrt-2.0.14-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libreport-2.0.15-1.fc17 abrt-2.0.14-2.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15498/abrt-2.0.14-2.fc17,libreport-2.0.15-1.fc17
then log in and leave karma (feedback).

Comment 18 Fedora Update System 2013-02-05 13:38:08 UTC
abrt-2.1.0-1.fc17,libreport-2.1.0-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.1.0-1.fc17,libreport-2.1.0-2.fc17

Comment 19 Fedora Update System 2013-03-20 08:41:58 UTC
abrt-2.1.2-1.fc17,libreport-2.1.2-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.1.2-1.fc17,libreport-2.1.2-1.fc17

Comment 20 Fedora End Of Life 2013-12-21 15:49:11 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. 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 '18'.

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 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 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, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

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.

Comment 21 Fedora End Of Life 2014-02-05 23:22:29 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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.