Red Hat Bugzilla – Full Text Bug Listing
|Summary:||virt-manager as non-root eats 100% CPU, works with --no-fork|
|Component:||GConf2||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED DEFERRED||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, crobinso, eparis, gianluca.cecchi, hbrock, jforbes, jrogers, patsev.anton, rstrode, sheltren, virt-maint, walters, walters|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-10-15 18:31:27 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description johnny.westerlund 2011-02-12 10:43:48 EST
Description of problem: when starting virt-manager as normal user it is not working correctly. Unable to add virtual guest is 1 example Version-Release number of selected component (if applicable): 0.8.6 How reproducible: 100% Steps to Reproduce: 1. Log on as normal user (no root) 2. start virt-manager (it prompts for authentication) 3. type your root password to start the application 4. try and use the program, it does not work as intended, cant create virtual guests etc Actual results: the program freeze on me, am unable to close some dialog boxes that i open. Expected results: Get a working virt-manager Additional info:
Comment 1 Jeff Sheltren 2011-03-13 11:45:24 EDT
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
Comment 2 Cole Robinson 2011-03-23 18:06:35 EDT
*** Bug 689124 has been marked as a duplicate of this bug. ***
Comment 3 Cole Robinson 2011-03-23 18:09:12 EDT
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?
Comment 4 johnny.westerlund 2011-03-24 17:40:40 EDT
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.
Comment 5 Jeff Sheltren 2011-03-25 22:31:14 EDT
(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.
Comment 6 Cole Robinson 2011-03-28 16:13:11 EDT
*** Bug 669803 has been marked as a duplicate of this bug. ***
Comment 7 Cole Robinson 2011-03-29 16:27:46 EDT
Created attachment 488558 [details] GDB trace of locked virt-manager process
Comment 8 Cole Robinson 2011-03-29 16:42:50 EDT
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
Comment 9 Cole Robinson 2011-03-29 16:53:26 EDT
> > 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
Comment 10 johnny.westerlund 2011-04-07 15:16:16 EDT
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
Comment 11 Colin Walters 2011-04-07 15:26:54 EDT
None of the desktop stack supports living across fork() basically. If you just need to drop the controlling tty, can you just call setsid() ?
Comment 12 Eric Paris 2011-04-07 15:34:47 EDT
Quick test for me shows F15 virt-manager working normally. I guess something changed/fixed it....
Comment 13 Jeff Sheltren 2011-04-07 15:49:18 EDT
(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
Comment 14 johnny.westerlund 2011-04-07 16:08:24 EDT
On my machine it's: GConf2-2.32.2-1.fc15.x86_64 virt-manager-0.8.7-2.fc15.noarch
Comment 15 Eric Paris 2011-04-07 16:16:57 EDT
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....
Comment 16 Eric Paris 2011-04-07 16:18:00 EDT
and I spoke too soon, just really slow to connect, but it just did and seems to be working....
Comment 17 Jeff Sheltren 2011-04-07 16:25:30 EDT
I updated to virt-manager-0.8.7-2.fc15 (currently in updates-testing), and I no longer experience the hang/CPU load.
Comment 18 Cole Robinson 2011-04-09 18:19:48 EDT
(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.
Comment 19 Gianluca Cecchi 2011-09-27 05:03:09 EDT
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
Comment 20 Cole Robinson 2012-10-15 18:31:27 EDT
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.