Vino-server takes 90% of cpu when only listening for incoming connections

Thanks for your bug. What version of Ubuntu do you use? Could you get a backtrace when that happens again:
- gdb $(pidof vino-server)
(gdb) thread apply all bt

Does it happen often?

I use breezy, with recent updates (dist-upgrade).
It happens once a week or so, but i can't find a pattern in the intervals. My pc is always turned on, (uptime is more dan 50 days) and i make several times per week a conncetion via vnc with my computer.

I am unfamiliar with gdb. Do i need root (sudo) rights before executing gdb $(vino pid) ?
When i now run gdb and typ "thread apply all bt" nothing is visible on the screen. Is there some output, and where? Or is "thread apply all bt" not something to typ..... Or is there only output if something goes wrong?

//Michiel

>Date: Fri, 10 Feb 2006 11:40:13 -0000
>
>Public bug report changed:
>https://launchpad.net/malone/bugs/31037
>
>Comment:
>Thanks for your bug. What version of Ubuntu do you use? Could you get a
>backtrace when that happens again:
>- gdb $(pidof vino-server)
>(gdb) thread apply all bt
>
>Does it happen often?

Hi Sebastien,

I posted again on the bug report, but got no answer. That is the reason i
trie it this way.
My cpu is now again 99 %. With top i can see vino-server takes 85 %
cpu-usage.
I want to use your recommedations but i am not familiar with the gdb. Can
you tell me wat to do? the pid off vino-server is 11812.

a screenshot is available at http://mifa.myftp.org/vino-load.png.
You can see gkrellm and top.

I now know it happend after one tried to make conact with my pc, but she
provided (on purpose) the wrong password. This gave the problem.

Can you help me?

With kind regards,
Michiel

i read some manpages and info on the web, and i got output of gdb.
It's located here: http://mifa.myftp.org/gdb-vino-output.txt.

I run gdb when cpu load is high. While gdb is running load goes normal (5%).
When i quit gdb i get this:
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /usr/lib/vino/vino-server, process 11812

My cpu load goes to 90 % again....

Thanks for your bug. THe wrong password information is useful. It happens on dapper too. I've forwarded your issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=332011

I am having the same problem. vino-server with 99% cpu utilization. Please fix or recomend an alternative.

Does it happen due to a wrong password for you too?

If a client is "on hold", then no processing will be performed in vino_server_update_client_timeout. However, the socket will therefore continue to be ready, and the GTK main loop will continually call this callback function.

Proposed fix: remove the client from the main loop when "on hold".

Ways to put a client on hold (for testing):
1. enable client authentication
2. turn off remote display altogether, and run vino-server manually

setting dapper as target since there is a patch

Patch has been accepted upstream, I can commit it for you Gary if you don't have an upstream CVS account. I've a package ready to update after the freeze for the dapper flight7 CD

I don't have an upstream CVS account. Do you want a reindented patch, or are you okay with the existing one?

I'll commit that tomorrow probably (friday), feel free to attach a version with the indentation fixed. If you don't I'll fix it before commiting anyway :)

Thanks for the work Gary, this upload fixes the issue:

 vino (2.13.5-0ubuntu6) dapper; urgency=low
 .
   * debian/patches/01_no_client_on_hold_loop.patch:
     - patch by Gary Coady <email address hidden>
     - The IO socket for clients on hold should not be included in the
       GTK main loop. Ubuntu: #31037

I have a problem where vino server shows no CPU usage, but it must be killed to prevent high CPU usage by other programs!!!?

I am using up to date Dapper and the problem occurs after my wife logs in to our home PC from work. When we get home, vino-server must be killed to prevent high CPU during mouse scrolling of any program.

I need assistance providing info for tracing down the problem so it can be reported properly.

That's probably a different issue, feel free to open a new bug describing what program has high CPU usage. You can get a backtrace as described on the http://wiki.ubuntu.com/DebuggingProgramCrash wiki page

I have the same problem! But the vino-server takes 30~60% of CPU... What's wrong?

Also appeared here on Feisty... Just a question that might sound silly, does openoffice has anything to do with vino-server? (it appears more frequent after launching/closing oo - it might be just an illusion)

Here is also Feisty... Why vino don't let the CPU alone?? =(

Same here, with Feisty! Just killed it.

Also had OO2.2 opened when noticed the high cpu usage by vino-server, no idea if that's a clue...

Please, somebody can fix this bug? I ever ever need to kill this process to play Second Life... =/

This happens to me too in Feisty. I have not had OOo open, I have not typed worng password (did not even try to log in before I saw the load). I have no idea what could have triggered the massive (90+%) load.

Please, somebody can fix this bug?

2007/8/4, Martin Pihl <email address hidden>:
>
> This happens to me too in Feisty. I have not had OOo open, I have not
> typed worng password (did not even try to log in before I saw the load).
> I have no idea what could have triggered the massive (90+%) load.
>
> --
> Vino-server takes 90% of cpu when only listening for incoming connections
> https://bugs.launchpad.net/bugs/31037
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I have found that Vino-server really does not like animated things on screen, especially in the panel at the top. I had a CPU monitor and a skype icon with a flashing alert flag on it, keeping up with these changes maxed out the CPU and made the remote session very unresponsive. Removing skype and the CPU panel applet seems to have fixed it for me.

> Removing skype and the CPU panel applet seems to have fixed it for me.

But that's not a fix, that's a workaround. Other VNC servers are quite capable of keeping up with a few updates per second. Vino should be similarly capable.

Yes.

2007/9/7, Chris Moore <email address hidden>:
>
> > Removing skype and the CPU panel applet seems to have fixed it for me.
>
> But that's not a fix, that's a workaround. Other VNC servers are quite
> capable of keeping up with a few updates per second. Vino should be
> similarly capable.
>
> --
> Vino-server takes 90% of cpu when only listening for incoming connections
> https://bugs.launchpad.net/bugs/31037
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This bug also appear on gutsy.
All goes fine but when some time elapsed, load of cpu reach 99% by vino-server and XOrg child process.
Also when i leave computer for long time i unable to unlock it. Screen is blinking black and no window renders

I am having the same issue on gutsy some times ... 99 % cpu taken by Xorg when vino-server is running. If I kill vino server, it fixes the problem...

Although this bugreport is quite old, I just have the same problem on hardy. After login, I noticed that vino-server uses 100% cpu on one core. Killing it with -TERM or -KILL is useless, as it gets started again right away.

Here's a backtrace:
(gdb) thread apply all bt

Thread 1 (Thread 0xb7071720 (LWP 7618)):
#0 0xb7288c00 in ?? () from /usr/lib/libtasn1.so.3
#1 0xb728afc0 in asn1_array2tree () from /usr/lib/libtasn1.so.3
#2 0xb77a774b in gnutls_global_init () from /usr/lib/libgnutls.so.13
#3 0x0805a80f in ?? ()
#4 0x0805c59c in ?? ()
#5 0x080562db in ?? ()
#6 0xb79d5429 in ?? () from /usr/lib/libgobject-2.0.so.0
#7 0xb79d5a18 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#8 0xb79d65d6 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0
#9 0xb79d66e0 in g_object_new () from /usr/lib/libgobject-2.0.so.0
#10 0x08053f65 in ?? ()
#11 0x08052cf7 in ?? ()
#12 0xb75a9450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#13 0x0804f561 in ?? ()
#0 0xb7288c00 in ?? () from /usr/lib/libtasn1.so.3
(gdb)

I have the same problem here yet.

On Thu, Aug 21, 2008 at 2:39 PM, Martin Emrich <email address hidden> wrote:

> Although this bugreport is quite old, I just have the same problem on
> hardy. After login, I noticed that vino-server uses 100% cpu on one
> core. Killing it with -TERM or -KILL is useless, as it gets started
> again right away.
>
> Here's a backtrace:
> (gdb) thread apply all bt
>
> Thread 1 (Thread 0xb7071720 (LWP 7618)):
> #0 0xb7288c00 in ?? () from /usr/lib/libtasn1.so.3
> #1 0xb728afc0 in asn1_array2tree () from /usr/lib/libtasn1.so.3
> #2 0xb77a774b in gnutls_global_init () from /usr/lib/libgnutls.so.13
> #3 0x0805a80f in ?? ()
> #4 0x0805c59c in ?? ()
> #5 0x080562db in ?? ()
> #6 0xb79d5429 in ?? () from /usr/lib/libgobject-2.0.so.0
> #7 0xb79d5a18 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
> #8 0xb79d65d6 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0
> #9 0xb79d66e0 in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #10 0x08053f65 in ?? ()
> #11 0x08052cf7 in ?? ()
> #12 0xb75a9450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
> #13 0x0804f561 in ?? ()
> #0 0xb7288c00 in ?? () from /usr/lib/libtasn1.so.3
> (gdb)
>
> --
> Vino-server takes 90% of cpu when only listening for incoming connections
> https://bugs.launchpad.net/bugs/31037
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I have the same problem on Hardy. Vino-server always works properly, the computer is running for days without any problem.But these days I have to do a very hard work. It tooks the computer several days working at 100%. I use VNC to see how the work is going from my job. No problem at all. Until I had Caps Lock on and fail typing password. After this, vino-server grows until 95% and was not be able to connect from VNC viewer and the work was very slow.
It seems the wrong password is the bug.

Hi chonps!

1) i running the vino-server (all time i monitoring the process)
2) connect from my laptop (missed the passwords five times)
3) nothing wrong happens

you can better explain?
what the version of your vino?

I am also seeing this in Ubuntu 9.04 amd64

Steps to reproduce:
1) System -> Preferences -> Remote Desktop
2) Check "Allow others to view your desktop"
3) Check "Allow others to control your desktop"
4) Uncheck "You must confirm access..."
5) Check "Require password..."
6) Check "Configure network automatically..."
7) Click Close. vino-server uses 100% CPU on both cores

Here is my backtrace:
--------------------------------
(gdb) thread apply all bt

Thread 1 (Thread 0x7f77c30ad7d0 (LWP 30016)):
#0 0x00007f77bfb9c566 in ?? () from /lib/libgcrypt.so.11
#1 0x00007f77bfb99ce7 in ?? () from /lib/libgcrypt.so.11
#2 0x00007f77bfb9a6be in ?? () from /lib/libgcrypt.so.11
#3 0x00007f77bfb97105 in ?? () from /lib/libgcrypt.so.11
#4 0x00007f77bfb6f9c1 in ?? () from /lib/libgcrypt.so.11
#5 0x00007f77bfb6fc8d in ?? () from /lib/libgcrypt.so.11
#6 0x00007f77bfb6fd33 in ?? () from /lib/libgcrypt.so.11
#7 0x00007f77bfdfc187 in _gnutls_dh_generate_prime ()
   from /usr/lib/libgnutls.so.26
#8 0x00007f77bfdfc2f2 in gnutls_dh_params_generate2 ()
   from /usr/lib/libgnutls.so.26
#9 0x0000000000416582 in ?? ()
#10 0x000000000041835c in ?? ()
#11 0x00000000004117bb in ?? ()
#12 0x00007f77c148a668 in ?? () from /usr/lib/libgobject-2.0.so.0
#13 0x00007f77c148ac03 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#14 0x00007f77c148b63b in g_object_new_valist ()
   from /usr/lib/libgobject-2.0.so.0
#15 0x00007f77c148b88c in g_object_new () from /usr/lib/libgobject-2.0.so.0
#16 0x000000000040ed7e in ?? ()
#17 0x000000000040d7a5 in ?? ()
---Type <return> to continue, or q <return> to quit---
#18 0x00007f77bf1ab5a6 in __libc_start_main () from /lib/libc.so.6
#19 0x000000000040a239 in ?? ()
#20 0x00007fffcb0ec258 in ?? ()
#21 0x000000000000001c in ?? ()
#22 0x0000000000000001 in ?? ()
#23 0x00007fffcb0edcb9 in ?? ()
#24 0x0000000000000000 in ?? ()
#0 0x00007f77bfb9c566 in ?? () from /lib/libgcrypt.so.11

Same problem here on jaunty i386

Confirm on Jaunty with:

H/W path Device Class Description
======================================================
                               system Computer
/0 bus Motherboard
/0/0 memory 1506MiB System memory
/0/1 processor Intel(R) Celeron(R) CPU 2.40GHz
/0/1/0 memory 8KiB L1 cache
/0/100 bridge 82865G/PE/P DRAM Controller/Host-Hub Interface
/0/100/1 bridge 82865G/PE/P PCI to AGP Controller
/0/100/1/0 display NV44A [GeForce 6200]
/0/100/1d bus 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #1
/0/100/1d.1 bus 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #2
/0/100/1d.2 bus 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #3
/0/100/1d.3 bus 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4
/0/100/1d.7 bus 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
/0/100/1e bridge 82801 PCI Bridge
/0/100/1e/1 multimedia Bt878 Video Capture
/0/100/1e/1.1 multimedia Bt878 Audio Capture
/0/100/1e/3 eth0 network VT6105/VT6106S [Rhine-III]
/0/100/1f bridge 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
/0/100/1f.1 scsi1 storage 82801EB/ER (ICH5/ICH5R) IDE Controller
/0/100/1f.1/0.0.0 /dev/cdrom disk DVD DD 2X16X4X16
/0/100/1f.2 storage 82801EB (ICH5) SATA Controller
/0/100/1f.3 bus 82801EB/ER (ICH5/ICH5R) SMBus Controller
/0/100/1f.5 multimedia 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
===

motherboard is Intel D865PERL
NVIDIA driver is latest recommended 180

$pkill vino-server

solves high CPU usage problem until reboot.

same problem in Jaunty here. Disabling remote desktop in preferences fixes the issue (but no remote access)
Running vino-server from a terminal window seems to be alright (no excessive CPU usage).

As soon as I enable remote desktop from the preferences menu, CPU spikes again.

AMD cpu.

Upgraded Nvidia driver to 180.60 this morning (problem existed before the upgrade).

I have the same problem in Jaunty. When vino-server is running, the CPU load is about 60-70%.

PC: AMD Athlon processor, 790G chipset, Radeon HD graphics with latest fglrx 9.6 driver

I get this, too.
Strange thing is, I don't know exactly what causes it - sometimes it happens, others it does not.
I wanted to prove that it was vino-server, so I installed the process accounting package (psacct or acct).
Attached is my lastcomm output - basically, this is just proof that the process keeps starting over and over.
What I notice is that there is one process of vino-server with no parameters, and the other, with the -sm-config-prefix, keeps getting created over and over...

A theory:
  Even though I DISABLED Remote-desktop in the preferences, a vino-server process (without the -sm...) keeps coming back and listening on port 5900. Can it be that gnome-session has remembered this application and wants to keep it alive? When the second process is spawned, it can not list on 5900, tries 5901 and dies (only to be reincarnated over and over).

mblackman@sharpie:~$ ps fax | grep vino
16188 pts/0 S+ 0:00 | \_ grep vino
16111 ? R 0:02 \_ /usr/lib/vino/vino-server
16185 ? Z 0:00 \_ [vino-server] <defunct>
16186 ? R 0:00 \_ /usr/lib/vino/vino-server --sm-config-prefix /vino-server-vSLB8H/ --sm-client-id 10149ef855f215a518124597273448955300000109050006 --screen 0
 7572 ? S 0:01 vino-preferences
mblackman@sharpie:~$ ps fax | grep vino
16195 pts/0 S+ 0:00 | \_ grep vino
16111 ? R 0:02 \_ /usr/lib/vino/vino-server
16193 ? R 0:00 \_ /usr/lib/vino/vino-server --sm-config-prefix /vino-server-vSLB8H/ --sm-client-id 10149ef855f215a518124597273448955300000109050006 --screen 0
 7572 ? S 0:01 vino-preferences

I confirm the same problem, Vino-server takes 90% of CPU. I am using Ubuntu 8.04 with all the updates (up to this time, June 2009).
After all this time of using this version of Ubuntu (8.04) it is for the first time when all of the sudden, without trying to use it, the vino-server jumps up and takes all the CPU power.
The only way of shutting it off is to go to System/Preferences/Remote Desktop and disable it from the Share check box and kill it after (otherwise it respawns itself).

This bug doesn't seem to be fixed, reopening...

I just noticed this behaviour of vino-server on a netbook (Acer AspireOne) running Jaunty. It did not occur before. I tried a restart and the CPU usage still went up after restart (to about 60%). Running top from terminal showed vino-server near the top of the list. Ran a killall on it and CPU went down to normal.

Someone mentioned capslock. I did happen to have caps lock on when I first noticed the problem. But I don't have it on now, so I don't know if that is related.

I also don't see the problem on my other computers yet (most of which also run Jaunty).

I also had this problem in 10.04 the first time I enabled remote desktop. vino-server was taking 98-99% of my CPU. I disabled remote desktop - which didn't kill the process - and then killed the process. When I re-enabled remote desktop, it was fine. No idea what triggered it, but whatever the bug is, it isn't fixed yet.

Finally! :D I'm so happy!! Thanks!

Still not fixed in 10.10?

In 10.10
While checked "Allow Users to View Your Desktop" "vino-server" process suddenly starts eating 50% of my dual-core CPU.
Killing the process helps.

I can confirm this in 10.10 as well - %CPU at 99 for vino-server. Even more, I didn't even have the "Allow Users to View Your Desktop" turned on...

On Maverick running under virtualbox on a win XP host (hey no choice, university will not stretch to a second machine for me and refuse to let me dual boot) I get this by opening up "Remote Desktop Preferences" Once it has checked connectivity and given the result, if I then deselect "Allow others to view your desktop" CPU usage jumps to 100%

htop has the offending command as

/usr/lib/vino/vino-server --sm-disable

This is repeatable at least for me on a fresh install and updated. Will try on home desktop this evening.

The same problem in Ubuntu 10.10

Please, fix it asap! :(

I just got this today in 10.10 for the first time. Killing the process worked.

I think this is connected to avahi, somehow. Everybody's backtraces seem to have avahi_entry_group_free() in them. People also can't kill the process without kill -9, which is consistent with it being inside a signal handler.

I can reproduce this by starting and stopping the vino daemon by clicking the "Allow other users to view your desktop" in the vino-preferences app. It consistently gets vino-server to peg a CPU.

However, if I first stop avahi:

    service avahi-daemon stop

before doing this, I can repeatedly start and stop vino without it pegging a CPU. My naive conclusion from this is that server/vino-mdns.c's call to avahi_entry_group_free() is freezing, spinning and sucking up CPU, but *ONLY* when avahi is running. This happens both when trying to restart the daemon or exit. Here's the vino code. I _think_ this makes it an avahi bug.

static void
vino_mdns_restart (void)
{
  if (mdns_service_name != NULL)
    g_free (mdns_service_name);
  mdns_service_name = NULL;

  if (mdns_entry_group != NULL)
    avahi_entry_group_free (mdns_entry_group);
  mdns_entry_group = NULL;

  if (mdns_client != NULL)
    avahi_client_free (mdns_client);
  mdns_client = NULL;

  vino_mdns_start (iface_name);
}

I was able to get this to work as well. I started the remote desktop server with system > preferences > remote desktop and checked the "share" box, then unchecked it by accident. The server originally gave indication that it could be connected to by going to one of the server's interfaces. When I re-checked the box, the vino process took up 99% of my CPU, and the server said that it was only accessible by localhost.

After reading through the bug to the very end, I saw that un-checking the share box, killing the process, and re-checking the share box worked for most people. That's what I did, and it worked for me.

I am running Ubuntu 10.04 x64

I can confirm having to kill vino-server due to 100% cpu after enabling and then disabling desktop sharing in system/preferences/remote desktop in Ubuntu 10.10 amd64. Can someone please reopen this bug, maybe set it to confirmed? Or should a new bug be opened up?

I hope you fix this bug...very impractical. also on ubuntu 10.10 64

This is still happening, so re-opening

Following DaveHansen's comment, if you stop avahi daemon, no CPU high usage. Ditto if you restart avahi daemon again after having stopped it. So seems it's indeed an avahi problem

are the avahi daemon developers aware of this bug?

I filed this:

http://avahi.org/ticket/324

Ubuntu 10.10 x64
I can also confirm that disabling Remote Desktop resolves that High CPU for vino-server

Once I reenable it, it comes right back

However, I can't disable it from the control panel without killing the process first. If i try, it just hangs.

I am the (new) Vino maintainer and can confirm that this bug (or at least, the version that DaveHansen found) is fixed in version 2.99.0 and above, so the fix will also be in a stable 3.0 release for GNOME 3. See https://bugzilla.gnome.org/show_bug.cgi?id=599104 for the upstream bug report.

Ok, trying to backport that for 2.32

This bug was fixed in the package vino - 2.32.1-0ubuntu2

---------------
vino (2.32.1-0ubuntu2) natty; urgency=low

  * debian/patches/03_exit-when-disabled.patch:
    - Add patch to make vino-server exit inmediately if not enabled (LP: #31037)
 -- Rodrigo Moya <email address hidden> Tue, 15 Mar 2011 19:06:27 +0100

Let's try if that works on natty and do stable update for other series later on once it's confirmed to be working

This seems to work for me all the times I try. Did anyone with the updated package in natty still see the high CPU usage and/or vino-server not exiting when disabling screen sharing?

high cpu usage on upgraded 11.04 -- should this be fixed in the setup as below? Cheers

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1636 ... 20 0 255m 29m 7980 R 56 0.8 52:36.40 vino-server

$dpkg -s vino
Architecture: amd64
Version: 2.32.1-0ubuntu2.1

$uname -a
Linux ... 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:24 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

This is still occurring in natty, fresh install.

I can confirm that I also am experiencing this bug often, on 10.10.

The issue has been fixed in 11.04 not 10.10, if you still get the issue in 11.04 you should open a new bug

Seems like it should be easy to backport the fix to lucid if somebody wants to work on that

Upgraded to 11.04, I still have this same problem (I do use Ubuntu Classic at loggin). I will open a new bug.

ubuntu 10.04.3 fresh+all latest official updates. cpu load >60% ( i tried different PCs, but result is the same).
That's really bad idea to include in distro broken vino package by default for 5 years.

p.s. Debian 6 doesn't have this issue.

Ubuntu 10.4 cpu load >89% for vino-server x32

I know this thread is kind of old and somewhat redundant. However, I do have 2 cents to add here. I saw mentioned a few times here that it seems like "vino-server" jumps up the CPU usage after a bad login attempt. I am running Lucid 10.04 and I use VNC quite a bit. I only found this thread because I too was experiencing high (90%) CPU usage when using VNC. I run at about 14% when not connected to Vino but the process is still running.

Here is my 2 cent comment as to the "Bad Login" attempts. I run about 9 computers on my network. I have 5 computers running Windows 2000, 1 running Windows XP, 2 Macs running 10.5.8 and now 1 running Ubuntu 10.04. My main "gateway" router is forwarding ports 5900, and so on, for VNC which is running on all computers on my network. On any given day my computer listening on port 5900 will get approx. 20 "Invalid Attempt" errors in my System Management Utility. This means that there are computers scanning the Internet looking for computers with port 5900 open and then tries to make the connection.

I'm just wondering if that is the problem that some are having here. You could possibly be getting these "Hack" attempts from outside. When they get the password wrong then it sends your CPU usage through the roof. Obviously you have no idea that the attempt is be made from the outside unless this can be monitored (Like in Windows). Just a little "food for thought"

I hope this information could possibly help somebody.
-Jim

Hello, Jim! Usually all devices in your network must be configured
with unique IP and MAC . If you connect to any host, you should know
the remote ip-address or host name.
If you have dublicated ip-addresses, the connection will be
established with the current IP in the ARP-table of your host. Verify
ip-addressing in the network, and you will be able connect to remote
host with the first attempt.

On Fri, Sep 16, 2011 at 1:59 AM, Jim Neel <email address hidden> wrote:
> I know this thread is kind of old and somewhat redundant. However, I do
> have 2 cents to add here. I saw mentioned a few times here that it seems
> like "vino-server" jumps up the CPU usage after a bad login attempt. I
> am running Lucid 10.04 and I use VNC quite a bit. I only found this
> thread because I too was experiencing high (90%) CPU usage when using
> VNC. I run at about 14% when not connected to Vino but the process is
> still running.
>
> Here is my 2 cent comment as to the "Bad Login" attempts. I run about 9
> computers on my network. I have 5 computers running Windows 2000, 1
> running Windows XP, 2 Macs running 10.5.8 and now 1 running Ubuntu
> 10.04. My main "gateway" router is forwarding ports 5900, and so on, for
> VNC which is running on all computers on my network. On any given day my
> computer listening on port 5900 will get approx. 20 "Invalid Attempt"
> errors in my System Management Utility. This means that there are
> computers scanning the Internet looking for computers with port 5900
> open and then tries to make the connection.
>
> I'm just wondering if that is the problem that some are having here. You
> could possibly be getting these "Hack" attempts from outside. When they
> get the password wrong then it sends your CPU usage through the roof.
> Obviously you have no idea that the attempt is be made from the outside
> unless this can be monitored (Like in Windows).  Just a little "food for
> thought"
>
> I hope this information could possibly help somebody.
> -Jim
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/31037
>
> Title:
>  Vino-server takes 90% of cpu when only listening for incoming
>  connections
>
> Status in Avahi:
>  New
> Status in GNOME Remote Desktop:
>  Fix Released
> Status in “vino” package in Ubuntu:
>  Fix Released
> Status in “vino” source package in Lucid:
>  Confirmed
> Status in Baltix GNU/Linux:
>  New
>
> Bug description:
>  The load of Vino-server becomes about 90 % of the cpu. It goes as far
>  as 99% of total cpu usage. A simple "killall vino-server" reduces cpu
>  load to 5-10 %. I have know idea why vino-server takes that much of
>  cpu. I didn't make any connection to it. It just happens after a
>  while.
>
>  [PLEASE: ANYBODY RE-OPEN THIS BUG BECAUSE IT REAPEAR ON FEISTY]
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/avahi/+bug/31037/+subscriptions
>

Thanks Mr Mike. That did it for me:

Mr. Mike (mike-himikeb) wrote on 2009-08-04: #42
I think gnome-session keeps restarting this process. What seems to be working for me, as a work-around, is to have Remote Desktop disabled in the session-preferences (gnome-session-properties).
Then, I use the command:
dbus-launch /usr/lib/vino/vino-server --display=:0.0 &

And I don't even use GNOME! I use XFCE! :-)

Hmmm, I spoke too soon. It was all good until I did a remote access, after disconecting vino-server starts hogging down the system with 50-100% CPU usage.

I just found this bug on two of my computers: One running Ubuntu 10.10, and this started happening without any VNC activity of any kind. The other computer runs Debian 6.0.3, but this started happening only after a successful VNC session.

in quantal - bug is still present

Vino server is killing my machine.

I use a Dell SX280 as a file server & to VPN. It worked flawlesly in ubuntu 10.04. After testing 12.04 on some other machines i decided to upgrade the server to 12.04. Big enormous mistake. Vino server at will puts the cpu to 99%, A vague idea is that at some point trying to VPN out-of-state to the box, the connection failed. Arriving home two days later the machine fan was screaming at full speed. This was 6 months ago.

Nowadays 12.04 also reports a system failure for samba and (I guess) tries to send an error report. No idea if it goes thru, nor if it is related.

My big problem is that I cannot find an answer/fix/workaround to prevent vino-server from overheating the little system.

Any advice is much appreciated.

Thanks.

Using 13.04 on a ION with 4G ram. The network is 1Ghz. If I remote login to this machine using VNC (Remmina Desktop client) vino-server utilizes 30-40% when I have one simple terminal up with "top" running. If I then simply move this terminal window the cpu goes to 99%+ for about 10 seconds and returns to 30-40%. Encryption and bit-depth does not seem to matter.

If I now use VNC from my ION to my 4-cpu i5-3570K @ 3.4Ghz Ubuntu 13.04 vino-server consumes 20-30% (of one of the cpus) when viewing a terminal running "top". If I perform some other activity, such as type this note in Firefox, vnc-server jumps to 40%. Typing is sluggish. Moving a window jumps it to 60% for several seconds. Again, bit-depth, encryption and quality make little difference.

I am happy to provide any other information that you might ask for.

I will probably be looking for another VNC solution since this baby is painful to use.

It effects badly Ubuntu 16.04 LTS on ASUS UX501VW it uses (at random) one to four of the 8 cores to 90+5 with no connections and nothing going on the desktop... just started and logged in.
This is a fresh install of Xenial Xerus with no customization, but all the latest updates installed.
Any info needed just ask.

I just noticed that the problem does not subsists if Vino/Desktop Sharing is not started with the option "Automatically configure UPnP router to open and forward ports" selected.
But if it started with this on, than de-selecting it does not bring the CPU usage down... Vino need to be "killed" 'cause too drunk... the process needs to be shut down and restarted; un-ticking the "Allow other users to view your desktop" and ticking it again has the same cycling effect.