Hide Forgot
Description of problem: virt-who can't report the virt.uuid in the terminal due to the virt.py:37: _init_:VirtError: Failed to connect socket to "/var/run/libvirt/libvirtd-sock-ro" Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Set the virt-who config file: VIRTWHO_DEBUG=1 2. Start libvirtd service 3. Start virt-who service Actual results: virt-who can't report the virt.uuid and the Automatic Bug Reporting Tool report"virt.py:37: _init_:VirtError: Failed to connect socket to "/var/run/libvirt/libvirtd-sock-ro"" Expected results: virt-who can report the virt.uuid and no the "virt.py:37: _init_:VirtError: Failed to connect socket to "/var/run/libvirt/libvirtd-sock-ro"" error info. Additional info:
This is regression introduced by the fix of bug 806225. It is caused by improper closing of file descriptors during the double fork.
This bug should be fixed in virt-who-0.6-4.el6.
(In reply to comment #4) > This bug should be fixed in virt-who-0.6-4.el6. Hi Radek, does the virt-who can't print the virt.uuids in terminal? The report infos are only in the /var/log/rhsm/rhsm.log.
(In reply to comment #8) > Hi Radek, does the virt-who can't print the virt.uuids in terminal? The report > infos are only in the /var/log/rhsm/rhsm.log. Yes, this is side effect of fixing bug 806225. I can reenable it for debug mode, but it can cause some problems. From my testing it seems that it's working ok, but I can't test all possible scenarios. Usually system daemons don't write anything to terminal when started by "service * start". This can be quite confusing, but I guess it's ok for debuging mode. So, I'll reenable writing to standard output in debug mode and if something breaks in your testing suite, we can disable it again. Do you agree?
(In reply to comment #10) > (In reply to comment #8) > > Hi Radek, does the virt-who can't print the virt.uuids in terminal? The report > > infos are only in the /var/log/rhsm/rhsm.log. > > Yes, this is side effect of fixing bug 806225. I can reenable it for debug > mode, but it can cause some problems. From my testing it seems that it's > working ok, but I can't test all possible scenarios. > > Usually system daemons don't write anything to terminal when started by > "service * start". This can be quite confusing, but I guess it's ok for > debuging mode. > > So, I'll reenable writing to standard output in debug mode and if something > breaks in your testing suite, we can disable it again. Do you agree? Hi Radek, According our communication in IRC, that will be updated. It should write virt.uuid to /var/log/rhsm/rhsm.log anyway and write to terminal only in debug mode. Thanks.
Next iteration, hopefully better. virt-who-0.6-5.el6
Verified the issue, the result is PASS. version: virt-who-0.6-5.el6.noarch subscription-manager-0.99.14-1.el6.x86_64 subscription-manager-firstboot-0.99.14-1.el6.x86_64 subscription-manager-gnome-0.99.14-1.el6.x86_64 python-rhsm-0.99.8-1.el6.noarch Details: [root@localhost ~]# service virt-who restart Stopping virt-who: [ OK ] Starting virt-who: [ OK ] [root@localhost ~]# Traceback (most recent call last): File "/usr/share/virt-who/subscriptionmanager.py", line 60, in connect if not self.connection.ping()['result']: File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 534, in ping return self.conn.request_get("/status/") File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 387, in request_get return self._request("GET", method) File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 348, in _request self.validateResponse(result) File "/usr/lib/python2.6/site-packages/rhsm/connection.py", line 364, in validateResponse raise RemoteServerException(response['status']) RemoteServerException Unable to obtain status from server, UEPConnection is likely not usable: Virt-who is running in libvirt mode Starting infinite loop with 3600 seconds interval and event handling Virtual machine found: rheltest-clone: 464574e4-1f41-b41f-8534-57c6b536bde7 Virtual machine found: rheltest: 0525b83f-cb9c-0963-82eb-ca22a428a08d Virtual machine found: test-clone3: 9f36a3d8-0df5-b1d6-e1d9-700a1830099d Virtual machine found: test-clone1: e38350ee-6836-4775-78c0-c59bef7029a0 Virtual machine found: test: af235184-c58d-a5bd-7ed6-fdaa991ce889 Sending list of uuids: ['0525b83f-cb9c-0963-82eb-ca22a428a08d', '464574e4-1f41-b41f-8534-57c6b536bde7', '9f36a3d8-0df5-b1d6-e1d9-700a1830099d', 'af235184-c58d-a5bd-7ed6-fdaa991ce889', 'e38350ee-6836-4775-78c0-c59bef7029a0']
Verified. Details as comment 17.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: virt-who can't connect to libvirtd Consequence: it has no information about guests Fix: open connection to libvirtd after fork so it won't get closed Result: virt-who can connect to libvirtd
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0900.html