Bug 806225 - virt-who don't do double fork when the daemon is starting.
Summary: virt-who don't do double fork when the daemon is starting.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-who
Version: 6.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: alpha
: ---
Assignee: Radek Novacek
QA Contact: Entitlement Bugs
URL:
Whiteboard:
Depends On:
Blocks: 738066
TreeView+ depends on / blocked
 
Reported: 2012-03-23 09:09 UTC by Hui Wang
Modified: 2016-12-01 00:30 UTC (History)
4 users (show)

Fixed In Version: virt-who-0.6-3.el6
Doc Type: Bug Fix
Doc Text:
Cause: virt-who didn't use double fork when starting Consequence: it didn't detach from terminal correctly Fix: use double forking Result: detaching from terminal works properly
Clone Of:
Environment:
Last Closed: 2012-06-20 14:14:32 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0900 0 normal SHIPPED_LIVE virt-who bug fix and enhancement update 2012-06-19 20:47:03 UTC

Description Hui Wang 2012-03-23 09:09:39 UTC
Description of problem:
There are two machine, machine1 and machine2. Run "ssh root@$remote_machine1_ip "service virt-who restart"" on machine2, the command will always not quit to shell process on machine2.

Version-Release number of selected component (if applicable):
virt-who-0.6-2.el6.noarch
subscription-manager-gnome-0.99.9-1.el6.x86_64
subscription-manager-0.99.9-1.el6.x86_64
subscription-manager-firstboot-0.99.9-1.el6.x86_64
python-rhsm-0.99.5-1.el6.noarch
libvirt-0.9.10-4.el6.x86_64


How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Run "ssh root@$remote_machine1_ip "service virt-who restart"" on machine2, the command will always not quit to shell process.

Expected results:
Run "ssh root@$remote_machine1_ip "service virt-who restart"" on machine2, the command will quit to shell process.

Additional info:
virt-who.py:

if options.background:
        try:
            pid = os.fork()
        except OSError:
            logger.error("Unable to fork, continuing in foreground")
            pid = 0

        if pid > 0:
            # Parent process
            sys.exit(0)

Comment 2 Radek Novacek 2012-03-29 13:29:57 UTC
As said in the summary, doing double-fork should fix this bug. Also virt-who
should properly redirect its std* to /dev/null. The fix is quite simple, but
there is some risk of breaking something.

This can be used as workaround:
ssh root@$remote_machine1_ip "service virt-who restart >/dev/null 2>/dev/null
&"

Comment 3 Radek Novacek 2012-03-30 08:40:06 UTC
This bug should be fixed in virt-who-0.6-3.el6.

Comment 5 J.C. Molet 2012-04-16 21:16:22 UTC
[root@cypher ~]# yum install virt-who

---> Package virt-who.noarch 0:0.6-3.el6 will be installed

>>>>>>>>>>>OUTPUT OMITTED<<<<<<<<<<<<

Complete!
[root@cypher ~]# vim /etc/rhsm/rhsm.conf
[root@cypher ~]# subscription-manager register --user=testuser1 --password=password --org=admin
The system has been registered with id: b2608a26-a2c1-481b-9cf3-72c2fa547c69 
[root@cypher ~]# service libvirtd start
Starting libvirtd daemon: [  OK  ]
[root@cypher ~]# service virt-who restart
Stopping virt-who: [FAILED]
Starting virt-who: [  OK  ]
[root@cypher ~]# hostname
cypher.idm.lab.bos.redhat.com


=== LATER ON MACHINE 2 ===

[jmolet@jmolet ~]$ for i in `seq 1 100`; do ssh root.lab.bos.redhat.com "service virt-who restart"; done
Stopping virt-who: [  OK  ]
Starting virt-who: [  OK  ]
.... (and many more)

There were no instances of a hang up anywhere here.

Marking VERIFIED.

Comment 6 Radek Novacek 2012-05-02 06:26:46 UTC
    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 didn't use double fork when starting

Consequence: it didn't detach from terminal correctly

Fix: use double forking

Result: detaching from terminal works properly

Comment 7 errata-xmlrpc 2012-06-20 14:14:32 UTC
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


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