Bug 598200

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

After some playing around, the following seems to be required:
dbus-uuidgen > /var/lib/dbus/machine-id

So it seems this must be done by rpm install (probably
some missing dependency?)
I reduced the number of warning by installing:

libcanberra-gtk2
PackageKit-gtk-module

libgnomebreakpad.so does not seems to be provided with rhel.

So the warnings need to be disabled or packages and dependencies added.

How did you install this machine? Certainly doesn't sound like that manual dbus step should be required. I wonder if some package dependencies are screwy, or maybe a kickstart config went over poorly? Can your provide the install logs from /root?

Reassigning to dbus for further triage.

dbus creates the machine ID on service start, if necessary.

I've just run into the same issue with NetworkManager:

[root@localhost ~]# nm-applet
process 1709: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/var/lib/dbus/machine-id": No such file or directory
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted


(In reply to comment #4)
> dbus creates the machine ID on service start, if necessary.    

yes, after 'service messagebus start' this error message goes away

so I don't think it is a dbus bug, but rather documentation issue ... dbus is not installed by default, only after some package that pulls it in its dependency chain, and then you either have to reboot (as it is chkconfig on by default) or run the service manually (as the rules forbid to start services automatically after installation) before using the application that has pulled it

taking a quick look, I don't see that mentioned in the Deployment Guide

Bill or Colin, what about adding that?

This isn't a unique issue; it's generally understood that you have to start a service after installing it if you want to use it, even if you enable it with chkconfig. I'm not sure why d-bus would merit special documentation here.

An issue here is that dbus can get pulled in by yum
as a dependency of an application.
This is unusual for services.
So I have no way to know that dbus was installed
and needs to be started.

I think the operating system should basically just come with a uuid by default (e.g. shipped with filesystem package), we can symlink the dbus one to that.  And the smolt one for that matter.

In Fedora 14 the plan will be that simply trying to connect to the dbus socket will start the daemon.  We could potentially achieve something similar for RHEL6 by having libdbus send a message to upstart, asking it to start the daemon.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6, and will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.