Created attachment 361825 [details] /var/log/messages Description of problem: Pressing the "boot message" ikon during log in screen gives the information that start of abrt daemon failed due to time out. Version-Release number of selected component (if applicable): How reproducible: boot f12_live_CD Steps to Reproduce: 1.boot 2.At log in screen press yellow exclamationmark button "boot messages" 3. Actual results: looking in var/log/messages I can see it has crashed. Expected results: no crash. no message. Additional info:
Me too. root@ontap:~# service abrtd restart Stopping abrt daemon: [FAILED] Starting abrt daemon: abrtd: Failed to start: timeout waiting for child [FAILED]
I suspect that abrt needs to check for /var/cache/abrtd and be able to recreate it if root has removed it. Its a chache; root should be able to remove any caches. manually doing a "mkdir /var/cache/abrt" didn't solve the problem though. root@ontap:~# /usr/sbin/abrtd abrtd: Failed to start: timeout waiting for child root@ontap:~# /usr/sbin/abrtd -d abrtd: inotify_add_watch failed on '/var/cache/abrt': No such file or directory root@ontap:~# mkdir /var/cache/abrt root@ontap:~# /usr/sbin/abrtd -d abrtd: Plugin SOSreport (0.0.2) succesfully loaded abrtd: Plugin Kerneloops (0.0.2) succesfully loaded abrtd: Plugin CCpp (0.0.1) succesfully loaded abrtd: Plugin Bugzilla (0.0.3) succesfully loaded abrtd: Plugin KerneloopsScanner (0.0.1) succesfully loaded abrtd: Plugin KerneloopsReporter (0.0.1) succesfully loaded abrtd: Plugin SQLite3 (0.0.2) succesfully loaded abrtd: Plugin TicketUploader (0.0.1) succesfully loaded abrtd: Plugin Mailx (0.0.2) succesfully loaded abrtd: Plugin RunApp (0.0.1) succesfully loaded abrtd: Plugin Logger (0.0.1) succesfully loaded abrtd: Plugin FileTransfer (0.0.6) succesfully loaded abrtd: Plugin Python (0.0.1) succesfully loaded abrtd: Registered plugin Bugzilla(Reporter) abrtd: warning: /proc/sys/kernel/core_pattern already contains |/usr/libexec/hookCCpp /var/cache/abrt %p %s %u, did abrt daemon crash recently? abrtd: Registered plugin CCpp(Analyzer) abrtd: Registered plugin Kerneloops(Analyzer) abrtd: Registered plugin KerneloopsReporter(Reporter) abrtd: Registered plugin KerneloopsScanner(Action) abrtd: Registered plugin Logger(Reporter) abrtd: Registered plugin Python(Analyzer) abrtd: Registered plugin SQLite3(Database) abrtd: dbus error: Connection ":1.75" is not allowed to own the service "com.redhat.abrt" due to security policies in the configuration file abrtd: Error requesting DBus name com.redhat.abrt, possible reasons: abrt run by non-root; dbus config is incorrect root@ontap:~# service abrtd restart Stopping abrt daemon: [FAILED] Starting abrt daemon: abrtd: Failed to start: timeout waiting for child [FAILED] root@ontap:~#
This should be fixed now. (1) we do not wait anymore for /var/cache/abrt scan to finish prior to reporting success in starting ourself (2) we do try to recreate /var/cache/abrt if it is not there
Description of problem: I'm having the same problem with my up2date Fedora 12 box. I can not start the abrtd service. Version-Release number of selected component (if applicable): abrt-1.0.0-1.fc12.x86_64.rpm Steps to Reproduce: 1. service abrtd start Actual results: Starting abrt daemon: abrtd: Failed to start: timeout waiting for child [FAILED] Expected results: No errors Additional info: I'm also using: kernel-2.6.31.9-174.fc12.x86_64.rpm abrt-addon-ccpp-1.0.0-1.fc12.x86_64.rpm abrt-addon-kerneloops-1.0.0-1.fc12.x86_64.rpm abrt-addon-python-1.0.0-1.fc12.x86_64.rpm abrt-desktop-1.0.0-1.fc12.x86_64.rpm abrt-gui-1.0.0-1.fc12.x86_64.rpm abrt-libs-1.0.0-1.fc12.x86_64.rpm abrt-plugin-bugzilla-1.0.0-1.fc12.x86_64.rpm abrt-plugin-kerneloopsreporter-1.0.0-1.fc12.x86_64.rpm abrt-plugin-logger-1.0.0-1.fc12.x86_64.rpm abrt-plugin-sqlite3-1.0.0-1.fc12.x86_64.rpm /var/log/messages looks like this: abrtd: Plugin SQLite3 (0.0.2) succesfully loaded abrtd: Plugin Python (0.0.1) succesfully loaded abrtd: Plugin KerneloopsScanner (0.0.1) succesfully loaded abrtd: Plugin Logger (0.0.1) succesfully loaded abrtd: Plugin Bugzilla (0.0.4) succesfully loaded abrtd: Plugin CCpp (0.0.1) succesfully loaded abrtd: Plugin KerneloopsReporter (0.0.1) succesfully loaded abrtd: Plugin Kerneloops (0.0.2) succesfully loaded abrtd: Registered plugin Bugzilla(Reporter) abrtd: warning: /proc/sys/kernel/core_pattern already contains |/usr/libexec/hookCCpp /var/cache/abrt %p %s %u, did abrt daemon crash recently? abrtd: Registered plugin CCpp(Analyzer) abrtd: Registered plugin Kerneloops(Analyzer) abrtd: Registered plugin KerneloopsReporter(Reporter) abrtd: Registered plugin KerneloopsScanner(Action) abrtd: Registered plugin Logger(Reporter) abrtd: Registered plugin Python(Analyzer) abrtd: Registered plugin SQLite3(Database) abrtd: dbus error: Connection ":1.48" is not allowed to own the service "com.redhat.abrt" due to security policies in the configuration file abrtd: Error requesting DBus name com.redhat.abrt, possible reasons: abrt run by non-root; dbus config is incorrect
re-opening per Cristian's request.
> abrtd: dbus error: Connection ":1.48" is not allowed to own the service "com.redhat.abrt" due to security policies in the configuration file abrtd: Error requesting DBus name com.redhat.abrt, possible reasons: abrt run by non-root; dbus config is incorrect We saw this a lot. dbus daemon wasn't understanding that dbus config was changed after abrt install. Doing "killall -HUP dbus-daemon" by hand was usually helping me. If this does not help, then - do you have /etc/dbus-1/system.d/dbus-abrt.conf file? Does it contain this? <busconfig> <!-- ../system.conf have denied everything, so we just punch some holes --> <policy user="root"> <allow own="com.redhat.abrt"/> <allow send_destination="com.redhat.abrt"/> <allow send_interface="com.redhat.abrt"/> </policy> <policy at_console="true"> <allow send_destination="com.redhat.abrt"/> </policy> <!-- Allow anyone to invoke methods on abrt server --> <policy context="default"> <allow send_destination="com.redhat.abrt"/> </policy> </busconfig>
(In reply to comment #7) > If this does not help, then - do you have /etc/dbus-1/system.d/dbus-abrt.conf > file? Does it contain this? > ... I have just reinstalled Fedora 12 on my computer, so the old configuration was lost.
(In reply to comment #8) > (In reply to comment #7) > > If this does not help, then - do you have /etc/dbus-1/system.d/dbus-abrt.conf > > file? Does it contain this? > > ... > > I have just reinstalled Fedora 12 on my computer, so the old configuration was > lost. The file: /etc/dbus-1/system.d/dbus-abrt.conf is part of abrt rpm, so it should be on the system, if it's not then there is something fishy going on your computer. J.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > If this does not help, then - do you have /etc/dbus-1/system.d/dbus-abrt.conf > > > file? Does it contain this? > > > ... > > > > I have just reinstalled Fedora 12 on my computer, so the old configuration was > > lost. > > The file: /etc/dbus-1/system.d/dbus-abrt.conf is part of abrt rpm, so it should > be on the system, if it's not then there is something fishy going on your > computer. I was only trying to say that my current configuration might different from the configuration that was used when I reopened the bug. Right now everything seems to work fine and /etc/dbus-1/system.d/dbus-abrt.conf looks just like you said. The list of currently installed packages is: abrt-1.0.6-1.fc12.x86_64.rpm abrt-addon-ccpp-1.0.6-1.fc12.x86_64.rpm abrt-addon-kerneloops-1.0.6-1.fc12.x86_64.rpm abrt-addon-python-1.0.6-1.fc12.x86_64.rpm abrt-desktop-1.0.6-1.fc12.x86_64.rpm abrt-gui-1.0.6-1.fc12.x86_64.rpm abrt-libs-1.0.6-1.fc12.x86_64.rpm abrt-plugin-bugzilla-1.0.6-1.fc12.x86_64.rpm abrt-plugin-logger-1.0.6-1.fc12.x86_64.rpm abrt-plugin-runapp-1.0.6-1.fc12.x86_64.rpm
Closing as WORKSFORME