Bug 1320125

Summary: trying to connect to "org.freedesktop.secrets" service fails after timeout if "gnome-keyring-daemon" is already running
Product: Red Hat Enterprise Linux 7 Reporter: mxie <mxie>
Component: dbusAssignee: David King <dking>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: juzhou, mclasen, mzhan, phrdina, tzheng, xiaodwan
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-23 14:39:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
virt-manager-debug.log
none
screenshot none

Description mxie@redhat.com 2016-03-22 11:08:39 UTC
Created attachment 1138989 [details]
virt-manager-debug.log

Description of problem:
Virt-manager will hang about 20sec when ssh connect to remote guest which has display password

Version-Release number of selected component (if applicable):
Host B:
virt-manager-1.2.1-8.el7.noarch
libvirt-1.2.17-13.el7_2.4.x86_64
qemu-kvm-1.5.3-105.el7_2.3.x86_64
spice-gtk-0.26-5.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Prepare two hosts: hostA is local server , hostB is test server

2.Preprare the guest which have display password on hostB, the guest's display could be vnc or spice
Open hardware details -> click "display" device and Set a password for it
-> start the guest on hostB

3.On the hostA, using SSH to connect hostB
#ssh root@hostB_ip -X

4.Launch"virt-manager" 
#virt-manager --debug

5.Select the guest which has display password and click "open" , then find virt-manager is hang, pls refer to screenshot and some virt-manager debug log as below, details log at attachment.
#virt-manager --debug
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/keyring.py", line 49, in __init__
    "org.freedesktop.Secret.Service", None)
Error: g-io-error-quark: Error calling StartServiceByName for org.freedesktop.secrets: Timeout was reached (24)


Actual results:
As above description

Expected results:
Virt-manager will not hang when ssh connect to remote guest which has display password

Addtional info:
Virt-manager will not hang when ssh connect to remote guest which has no display password

Comment 1 mxie@redhat.com 2016-03-22 11:11:01 UTC
Created attachment 1138990 [details]
screenshot

Comment 3 Pavel Hrdina 2016-06-03 17:49:35 UTC
After some digging and investigating I was able to reproduce this bug.  But this doesn't seems to be a virt-manager issue.

To reproduce this bug you need to start a host with GUI and log into that host as "root".  This starts gnome-keyring-daemon:

    1874 ?        Sl     0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

As a next step connect to the same host via ssh "ssh -X root@$host" and run this simple python script:

    import dbus
    bus = dbus.SessionBus()
    service = bus.get_object("org.freedesktop.secrets", "/org/freedesktop/secrets")

which will fail with following exception:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 241, in get_object
    follow_name_owner_changes=follow_name_owner_changes)
  File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 278, in start_service_by_name
    'su', (bus_name, flags)))
  File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 651, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: 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.

And system log contains this record:

    gnome-keyring-daemon[1845]: The Secret Service was already initialized

I'm not sure if gnome-keyring or dbus is the right component, so I'll let someone else decide.  Moving to dbus.