Bug 469116 - virt-manager silently exits when guest installation completes or is killed
virt-manager silently exits when guest installation completes or is killed
Product: Virtualization Tools
Classification: Community
Component: virt-manager (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Depends On:
  Show dependency treegraph
Reported: 2008-10-29 19:41 EDT by Chris Snook
Modified: 2010-03-16 13:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-23 10:46:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Snook 2008-10-29 19:41:47 EDT
Description of problem:
Whenever a guest that is being installed terminates, either because installation has completed and it's rebooting, or the administrator has forcibly killed the guest, virt-manager exits, taking out all open guest consoles.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install Fedora 10 Snap 2 and update to latest.  (Installing F10-Snap3 would probably suffice.)
2. Start an installation with virt-manager.
3. Kill the installation with Force Shutdown.

Actual results:
virt-manager disappears, along with any windows it had opened, including unrelated guests.  No error message is printed on the console virt-manager was launched from.

Once the guest has been installed, killing it with Force Shutdown has no adverse effects.

Expected results:
virt-manager survives.  The VM window should probably survive too.

Additional info:
Only tested invoking virt-manager over ssh -X from up-to-date Fedora 8 machines, but no X messages appear on the console other than the following, which appears when starting virt-manager and seems to have no adverse effects on this or any other X app:

Xlib:  extension "RANDR" missing on display "localhost:10.0".
Comment 1 Cole Robinson 2008-10-30 09:26:23 EDT
Can you try to reproduce running virt-manager with --no-fork from the command line and see if something is printed when the app closes? I'll try to reproduce as well.
Comment 2 Chris Snook 2008-10-30 13:04:37 EDT
I tried running with --no-fork, this time ssh-ing in from a box that's running F9 plus whatever rawhide packages that rawhide virt tools pull in.  When I did the force poweroff, some message about a failed TCP connection flashed momentarily in the GUI window, and then it shows "guest not running", as would be expected, and nothing died that shouldn't have.  Nothing was printed on the console when I killed the guest.

I'll try again sshing in from an F8 box tonight.  I'm guessing this isn't a problem running locally, otherwise everyone running virt-manager on rawhide would be seeing it.  This could just be an F8 bug, but it could also be that virt-manager or dbus-x11 is assuming too much about the X server.
Comment 3 Chris Snook 2008-10-31 12:22:45 EDT
Interesting.  Running with --no-fork when SSHd in from F8 (where the problem happens) causes the same behavior as my F9 test.  I never actually tested F9 without --no-fork.  It appears that --no-fork makes the problem go away.  Fun.
Comment 4 Cole Robinson 2008-10-31 12:29:44 EDT
Hmm. There was a problem similar to this where the app wouldn't start: it was related to dbus and X. I'll try and reproduce and see if I can gather anything.
Comment 5 Cole Robinson 2008-12-02 11:58:40 EST
Any chance you are running F10 or rawhide? There was a fix in this area that I think may solve the issue. Wondering if you could give it a test?
Comment 6 Cole Robinson 2009-01-23 10:46:56 EST
I'm pretty certain this was solved with fixes applied to virt-manager 0.6.0 in f9 and f10, so closing as CURRENTRELEASE. Please reopen if you can still reproduce, and include

virt-manager version
local and remote host distros
result of trying with and without --no-fork

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