Bug 488878 - GConf error when starting virt-manager-0.6.1-1.fc10 after "su" (works with "su -")
GConf error when starting virt-manager-0.6.1-1.fc10 after "su" (works with "s...
Status: CLOSED DUPLICATE of bug 474523
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
10
All Linux
high Severity high
: ---
: ---
Assigned To: Daniel Berrange
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-05 21:12 EST by James Ralston
Modified: 2013-11-04 03:32 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-10 16:40:52 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)

  None (edit)
Description James Ralston 2009-03-05 21:12:59 EST
I updated to virt-manager-0.6.1-1.fc10 from updates-testing. Attempting to start virt-manager now dies with the following dialog box:

Error starting Virtual Machine Manager: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)

Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager.py", line 368, in <module>
    main()
  File "/usr/share/virt-manager/virt-manager.py", line 299, in main
    icon_dir, data_dir)
  File "/usr/share/virt-manager/virtManager/config.py", line 51, in __init__
    gconf.CLIENT_PRELOAD_NONE)
GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details -  1: Failed to get connection to session: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)

I reverted to virt-manager-0.6.0-5.fc10.x86_64 from updates, which works fine.

Versions of all *virt* packages:

0:libvirt-0.6.1-1.fc10.x86_64
0:libvirt-python-0.6.1-1.fc10.x86_64
0:python-virtinst-0.400.2-1.fc10.noarch
0:virt-manager-0.6.0-5.fc10.x86_64
0:virt-top-1.0.3-2.fc10.x86_64
0:virt-viewer-0.0.3-3.fc10.x86_64
Comment 1 Cole Robinson 2009-03-05 23:02:14 EST
Thanks for testing this.

With the older version, assuming you start running as a regular user, are you entering root credentials when the app starts or are you click 'Run Unprivileged'?

Anything interesting with your setup? NFS home dir, running over ssh. Can you try running from the command line, see if it helps, possibly trying the --no-fork flag?
Comment 2 James Ralston 2009-03-09 14:21:20 EDT
As far as I can tell, virt-manager-0.6.1-1.fc10 only fails to launch if I launch it from a root terminal.  Adding --no-fork doesn't help.

It works fine it I launch it via a regular account, either via the command line, or by picking it off of the GNOME menu.  Both authenticating and running unprivileged work fine.
Comment 3 Cole Robinson 2009-03-09 14:38:45 EDT
As asked in Comment #1, how were you launching virt-manager with the older version?

With the new version, are you using sudo, su, or su -? Do you have NFS home directories or anything like that? Is there any reason why root wouldn't have access to files in your home directory?
Comment 4 James Ralston 2009-03-09 15:49:53 EDT
I launch all versions of virt-manager the same way: from a root shell that I open via "su".

I am not using NFS home directories.  I can think of no reason why root wouldn't have access to files in my home directory.
Comment 5 Cole Robinson 2009-03-09 21:41:31 EDT
Hmm, really not sure what the issue is. The only thing that changed that would effect this is dropping ConsoleHelper (the 'Run Unprivileged') dialog. I would think that launching virt-manager as root in both cases wouldn't yield any difference.

Sorry for the pestering, but does running 'su -' as opposed to just plain 'su' make any difference?
Comment 6 James Ralston 2009-03-10 11:06:53 EDT
I just tested that, and yes, it does; virt-manager-0.6.1-1.fc10 launches properly if I su to root via "su -" instead of just "su".
Comment 7 Cole Robinson 2009-03-10 11:40:06 EDT
Hmm, looks like this is an example of:

https://bugzilla.redhat.com/show_bug.cgi?id=474523
Comment 8 James Ralston 2009-03-10 16:22:43 EDT
Yeah, that's it.

The weird thing is, though: why did dropping ConsoleHelper trigger this problem, when previous versions ran just fine?

(Feel free to close this as a dupe of bug 474523.)
Comment 9 Cole Robinson 2009-03-10 16:40:52 EDT
ConsoleHelper probably sees if the app is launched by the root user, and makes sure that everything is run from root's environment. This prevents issues like 'su virt-manager' creating root owned log files in the original users HOME, which can understandably cause issues.

Closing as dup of bug 474523.

*** This bug has been marked as a duplicate of bug 474523 ***
Comment 10 rhindaileh 2013-11-04 03:32:44 EST
I had this issue before, I worked around it by removing the gconf from home directory of the user with this issue, and it worked
mv ~/.gconf ~/.gconf.old
mv ~/.gconfd ~/.gconfd.old

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