Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Descriptionmxie@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
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.
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