Bug 488878

Summary: GConf error when starting virt-manager-0.6.1-1.fc10 after "su" (works with "su -")
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: virt-managerAssignee: Daniel Berrangé <berrange>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 10CC: berrange, crobinso, hbrock, markmc, quintela, rhindaileh, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-03-10 20:40:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description James Ralston 2009-03-06 02:12:59 UTC
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-06 04:02:14 UTC
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 18:21:20 UTC
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 18:38:45 UTC
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 19:49:53 UTC
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-10 01:41:31 UTC
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 15:06:53 UTC
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 15:40:06 UTC
Hmm, looks like this is an example of:

https://bugzilla.redhat.com/show_bug.cgi?id=474523

Comment 8 James Ralston 2009-03-10 20:22:43 UTC
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 20:40:52 UTC
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 08:32:44 UTC
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