Bug 677020 - virt-manager as non-root eats 100% CPU, works with --no-fork
virt-manager as non-root eats 100% CPU, works with --no-fork
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: GConf2 (Show other bugs)
rawhide
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
: 669803 689124 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-12 10:43 EST by johnny.westerlund
Modified: 2012-10-15 18:31 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-15 18:31:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
GDB trace of locked virt-manager process (41.91 KB, text/plain)
2011-03-29 16:27 EDT, Cole Robinson
no flags Details

  None (edit)
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.

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