"yum install abrt-desktop" is meant to be used by people who want out-of-the-box working abrt, without tweaking any config files and such. It does install all plugins required by default configuration.

You are free to install abrt components by hand. For example, you can choose to not install abrt-plugin-bugzilla. But then you will need to change the configuration file so that it doesn't use bugzilla plugin (most usual case is when you want to use different reporting plugin).

Please let me know where this can be documented better to prevent others from falling into the same trap you are in.

From one point of view: This was an upgraded system, and after the upgrade a service was failing. That is a unfortunate regression.

Another point of view: The users who want out-of-the-box working abrt do not read any documentation but just installs the abrt package and expect that to be sufficient. They will never find the abrt-desktop package. It would be nice if abrt was renamed to abrt-daemon and abrt-desktop was renamed to abrt. It might be possible with some clever epoch tricks.

Third point of view: If the default configuration of abrtd requires abrt-plugin-bugzilla then there should be a package dependency. Alternatively abrt-plugin-bugzilla could have its own configuration in the conf.d/ style.

(FWIW: I don't understand why abrt is split up in so many packages. It is fine to break dependency chains, but this seems to be over-engineered. The number of abrt packages and/or their naming have however improved a lot. And "addon" and "plugin" are almost synonyms to me, and the difference doesn't tell a system administrator anything. For example "handler" and "reporter" would be more descriptive. "abrt-handler-coredumps" tells me a lot more than than "abrt-addon-ccpp". But this getting off-topic...)

Fourth point of view: IF the abrtd daemon fails to start then "abrtd: Failed to start: got sig 2" doesn't help and shouldn't be shown.

(In reply to comment #2)
> From one point of view: This was an upgraded system, and after the upgrade a
> service was failing. That is a unfortunate regression.
> 

I went thru the dependencies in spec file and found one possible case when this may happen. User upgrades from Fedora < 12 and has kerneloops installed. In this case it brings only these packages: abrt, abrt-libs and abrt-addon-kerneloops, the abrt-desktop is installed only if there was bug-buddy installed. So I'm wondering if this is the case.

> Third point of view: If the default configuration of abrtd requires
> abrt-plugin-bugzilla then there should be a package dependency. Alternatively
> abrt-plugin-bugzilla could have its own configuration in the conf.d/ style.
> 

Yes, that's planned.

> (FWIW: I don't understand why abrt is split up in so many packages. It is fine
> to break dependency chains, but this seems to be over-engineered. 

The idea is to keep every plugin in separate package, we're trying to put together the packages which can't work without each other, but I don't think we will reduce the number significantly.

The number of
> abrt packages and/or their naming have however improved a lot. And "addon" and
> "plugin" are almost synonyms to me, and the difference doesn't tell a system
> administrator anything. For example "handler" and "reporter" would be more
> descriptive. "abrt-handler-coredumps" tells me a lot more than than
> "abrt-addon-ccpp". But this getting off-topic...)
> 
> Fourth point of view: IF the abrtd daemon fails to start then "abrtd: Failed to
> start: got sig 2" doesn't help and shouldn't be shown.  

Yes, the error message should be more descriptive.

> I went thru the dependencies in spec file and found one possible case when this
> may happen. User upgrades from Fedora<  12 and has kerneloops installed. In
> this case it brings only these packages: abrt, abrt-libs and
> abrt-addon-kerneloops, the abrt-desktop is installed only if there was
> bug-buddy installed. So I'm wondering if this is the case.

Yes, I think that was the case.

IIRC some abrt package in F11 (other than abrt-desktop?) conflicted/replaced bug-buddy. Because the F11 version was so old I gave up and probably removed most of it.

>> Third point of view: If the default configuration of abrtd requires
>> abrt-plugin-bugzilla then there should be a package dependency. Alternatively
>> abrt-plugin-bugzilla could have its own configuration in the conf.d/ style.
> 
> Yes, that's planned.

But until that happens and the bugzilla configuration is moved to the bugzilla package then there will be a de facto dependency from content of abrt to content of the bugzilla package? I think that should be reflected in the package dependencies.

*** Bug 553700 has been marked as a duplicate of this bug. ***

I installed the abrt-desktop which found several dependencies (including the Bugzilla one) to install, and I no longer get the "Failed" message during boot.

And, FYI, my installation was not a F11 upgrade; it was transitioned to a F12 system from a Rawhide F12 one.

Ah thanks, I filed a bug about the same issue. As for documentation, this bug report did it for me..

I experienced the bug as a regression, it came after an upgrade. If it matters, I upgraded from f11 via preupgrade weeks ago. After installing abrt-desktop, the init script runs just fine. Could you guide me to some manual configuration that was mentioned earlier?

*** Bug 553981 has been marked as a duplicate of this bug. ***

Currently a new install or upgrade to F12 will show a alarm on the desktop stating that ABRT could not start.  This would normally indicate to the user that there is an error.  I think it would make sense to not add abrt-plugin-bugzilla as a dependency, but rather to add abrt-desktop to the default package install list for anaconda.

Also, it'd be good to get this issue documented somewhere.  I will look into where the best place to do this is.

Jason: That somewhere should be http://fedoraproject.org/wiki/Common_F12_bugs. If you don't know or couldn't find that page then it just means that the page has a marketing problem ;-)

(By the way: bug 543725 now shows the same error message - but apparently for a different reason.)

(In reply to comment #10)
> Jason: That somewhere should be http://fedoraproject.org/wiki/Common_F12_bugs.
> If you don't know or couldn't find that page then it just means that the page
> has a marketing problem ;-)
> 

I added an entry to https://fedoraproject.org/wiki/Common_F12_bugs for the ABRT issue.

Also, I opened a release notes ticket for the addition of the ABRT information.
https://bugzilla.redhat.com/show_bug.cgi?id=555387

> (By the way: bug 543725 now shows the same error message - but apparently for a
> different reason.)    

I checked out bug 543725 and it is not directly related to this issue.  Rather it is a traceback that was generated when you try to run the ABRT GUI when the ABRT service is not running.  It's what the ABRT GUI does when it can't connect to the ABRT service.

I also update a few days ago and I am facing the same problem.
When I start abrtd in the console, there is a different message in the log

Feb  1 22:23:11 localhost abrtd: can't load '/usr/lib64/abrt/lib.so': /usr/lib64/abrt/lib.so: cannot open shared object file: No such file or directory

Could not found a work around so far.

"can't load '/usr/lib64/abrt/lib.so'" is the result of load attempt for plugin named "" (i.e. empty string). This needs to be researched.

Please do as root:

killall abrtd
abrtd -dvvv


wait a few secs, then ^C running abrtd and cut-n-paste abrtd's on-screen log here.

Hi Denys,
Sorry too late. I remove abrtd with yum and installed the service again. Voilà it's back working again. Easy workaroung I am happy :-) Sirene-Signal is gone.
Cheers
Suvi.org

*** This bug has been marked as a duplicate of bug 560642 ***