Bug 598200 - D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/var/lib/dbus/machine-id'
D-Bus library appears to be incorrectly set up; failed to read machine uuid: ...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: dbus (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Colin Walters
Desktop QE
:
Depends On:
Blocks: 1002711
  Show dependency treegraph
 
Reported: 2010-05-31 13:57 EDT by Michael S. Tsirkin
Modified: 2013-10-06 21:33 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-06 21:33:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 478013 None None None Never

  None (edit)
Description Michael S. Tsirkin 2010-05-31 13:57:28 EDT
Description of problem:
ssh -X root@virtlab16
[root@virtlab16 ~]# virt-manager
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory
Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory
Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory
process 5095: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/var/lib/dbus/machine-id' should contain a hex string of length 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

Version-Release number of selected component (if applicable):
virt-manager-0.8.4-3.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. ssh -X to rhel6 machine (minimal install)
2. yum install virt-manager
3. virt-manager
  
Actual results:
fails with errors above

Expected results:
should not fail

Additional info:
Comment 1 RHEL Product and Program Management 2010-05-31 14:16:18 EDT
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.
Comment 2 Michael S. Tsirkin 2010-05-31 14:19:50 EDT
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.
Comment 3 Cole Robinson 2010-06-01 13:47:47 EDT
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.
Comment 4 Bill Nottingham 2010-06-02 12:15:15 EDT
dbus creates the machine ID on service start, if necessary.
Comment 5 Karel Volný 2010-06-21 10:44:42 EDT
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?
Comment 6 Bill Nottingham 2010-06-21 15:10:24 EDT
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.
Comment 7 Michael S. Tsirkin 2010-06-23 04:46:58 EDT
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.
Comment 8 Colin Walters 2010-06-23 09:23:38 EDT
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.
Comment 9 Colin Walters 2010-06-23 14:41:00 EDT
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.
Comment 10 RHEL Product and Program Management 2010-07-15 10:16:56 EDT
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. **
Comment 15 Andrius Benokraitis 2013-10-06 21:33:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.