Bug 677020

I'm also seeing this on F15 alpha using virt-manager-0.8.6-2.fc15.noarch.

If I sudo su - in a shell and run virt-manager from there I can add a virtual machine as expected.  However, if I run virt-manager from the gnome menu and authenticate, clicking on the 'new vm' button causes a python process to launch and eat up tons of CPU.  Doing an strace on the process shows a bunch of:

sched_yield()                           = 0

*** Bug 689124 has been marked as a duplicate of this bug. ***

Can anybody still reproduce with latest rawhide or f15?

Is there a specific step that the app always freezes at? Comment #1 mentions clicking 'new vm', are other people seeing that? Any other reproducers, like launching a VM console or opening other dialogs?

Do other apps have similar results? How bout things like system-config-firewall or system-config-services?

I still have the same problem. I have not reinstalled since verry early fedora 15 branch so if its something else than whats in the base packages i dont know. Anyway did some short testing tonight and running virt-manager straight up still produces the hang for me. Here's the wierd part though. If i start virt-manager --debug everything works just fine for me. I can start/stop machines i can open settings and so on. But if i start virt-manager without --debug either via the gnome3 activities or by terminal i get the hang problem. Top output shows python eating 100% or close to that of the CPU. 

I read what --debug does and it implies --no-fork so i started virt-manager with --no-fork and then in works fine aswell.... so --no-fork makes it work.

(In reply to comment #3)
> Can anybody still reproduce with latest rawhide or f15?
> 
Is there anything newer than 0.8.6-2.fc15?  I don't see any updates to virt-manager in updates-testing.

> Is there a specific step that the app always freezes at? Comment #1 mentions
> clicking 'new vm', are other people seeing that? Any other reproducers, like
> launching a VM console or opening other dialogs?

Yes, I also see the problem when clicking on an existing VM and clicking 'open'.


> Do other apps have similar results? How bout things like system-config-firewall
> or system-config-services?

Not that I can tell.

*** Bug 669803 has been marked as a duplicate of this bug. ***

Created attachment 488558 [details]
GDB trace of locked virt-manager process

I've tried narrowing this down a bit. Simplest reproducer:

- Run virt-manager as a regular user
- File->Add Connection, app locks up before dialog is launched

This doesn't require actually connecting to anything, so libvirt and policykit don't factor in. The app is actually locking up reading the 'add connection' glade file, which is basically:

            self.window = gtk.glade.XML("vmm-open-connection.glade",
                                        "vmm-open-connection",
                                        domain="virt-manager")

The main thing that we are doing which is tickling the lockup is daemonizing the app. This is the default way we run virt-manager, since we need to drop the controlling tty in order for ssh to launch the askpass dialog if the user is connecting to remote connections with ssh keys.

Currently we initialize gconf _before_ daemonizing, as recommended by halfline a while back since it caused problems. Code is roughly:

    # Specifically init config/gconf before the fork, so that pam
    # doesn't think we closed the app, therefor robbing us of
    # display access
    ...
    conf = gconf.client_get_default()

If I move gconf initialization _after_ daemonizing, the problem goes away. If I hack out gconf usage, the problem goes away. If we don't daemonize, the problem goes away.

Reassigning to gconf for now, any input from gnome devs?

$ rpm -q GConf2
GConf2-2.32.1-8.fc15.x86_64

> 
> The main thing that we are doing which is tickling the lockup is daemonizing
> the app. This is the default way we run virt-manager, since we need to drop the
> controlling tty in order for ssh to launch the askpass dialog if the user is
> connecting to remote connections with ssh keys.

*without ssh keys

I've run some test todays, i've applied all the patches for fedora 15.
virt-manager no longer hangs. I've been unable to reproduce the bug. So some package that i've updated fixes the problem.

/J

None of the desktop stack supports living across fork() basically.  If you just need to drop the controlling tty, can you just call setsid() ?

Quick test for me shows F15 virt-manager working normally.  I guess something changed/fixed it....

(In reply to comment #12)
> Quick test for me shows F15 virt-manager working normally.  I guess something
> changed/fixed it....

Are you opening virt-manager via the gnome application menu?

What version of Gconf2, virt-manager, etc.?

I am still experiencing the same behavior I described in comment #1

On my machine it's:

GConf2-2.32.2-1.fc15.x86_64
virt-manager-0.8.7-2.fc15.noarch

I was opening via the favorites menu and it worked fine.  However I just launched virt-manager from a gnome-terminal tried to connect to a remote machine and it seems to have locked up.  Not spinning 100% cpu, but not working either....

and I spoke too soon, just really slow to connect, but it just did and seems to be working....

I updated to virt-manager-0.8.7-2.fc15 (currently in updates-testing), and I no longer experience the hang/CPU load.

(In reply to comment #11)
> None of the desktop stack supports living across fork() basically.  If you just
> need to drop the controlling tty, can you just call setsid() ?

After googling for a while, I can't find a way to make setsid work without forking first, but my UNIX API knowledge isn't that exhaustive. danpb wrote the original code, maybe he has some ideas about possible workarounds.

In fedora at the moment I moved gconf init after forking, so the problem is worked around for now. that did cause some problems in the past, but things seem to function okay for the time being.

I have this problem with F15 + virt-preview too:
virt-manager-0.9.0-5.fc15.noarch
With all my vms powered off as I start virt-manager and double click on a guest row it hangs..

top - 10:01:30 up 55 min,  6 users,  load average: 1.23, 0.92, 0.56
Tasks: 170 total,   3 running, 167 sleeping,   0 stopped,   0 zombie
Cpu(s): 10.2%us, 46.0%sy,  0.0%ni, 42.3%id,  1.3%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   4056320k total,  2235448k used,  1820872k free,    87908k buffers
Swap:   506012k total,        0k used,   506012k free,   971616k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15474 gcecchi   20   0  804m  47m  13m R 100.0  1.2   1:36.06 python


# strace -p 15474
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0
sched_yield()                           = 0

Starting wit "--no-fork" solves the problem.
I only get:
[gcecchi@ope46 ~]$ virt-manager --no-fork
/usr/share/virt-manager/virtManager/console.py:656: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  pages.add(self.fs_drawer)

But I'm able to work...
Let me know if you need any debug info on my side to help solve.

Gianluca

This bug has just lingered for a while, clearing needinfo and closing. If anyone can still reproduce with F17+, please reopen and adjust the fedora version.