Bug 1320125 - trying to connect to "org.freedesktop.secrets" service fails after timeout if "gnome-keyring-daemon" is already running
Summary: trying to connect to "org.freedesktop.secrets" service fails after timeout if...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: dbus
Version: 7.3
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: David King
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-22 11:08 UTC by mxie@redhat.com
Modified: 2019-09-23 14:39 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-23 14:39:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
virt-manager-debug.log (9.32 KB, text/plain)
2016-03-22 11:08 UTC, mxie@redhat.com
no flags Details
screenshot (20.99 KB, image/png)
2016-03-22 11:11 UTC, mxie@redhat.com
no flags Details

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.


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