Fedora 30 with a KVM/qemu virtual machine running Ubuntu 18.04.1.

(This setup because I want to run RStudio and on my Fedora 30, and it just barfs & dies immediately somewhere in the nouveau graphics subsystem -- but runs well in an Ubuntu VM).


Copy & Paste in the VM is a right PITA when RStudio is running.

After the VM has been started, copy-paste between host and VM works well, and copy&paste inside the VM also works well (for example KWrite to KWrite)

Once RStudio has been started in the VM, copy & paste initially continues to work (a few times) but soon starts to "lock up". This applies to both RStudio and KWrite and happens both for in-VM and host-to-VM copy&paste. The receiving process in the VM freezes and apparently waits for something. However, the virtual machine continues to otherwise perform normally (e.g. you can exercise the shell, run top, iotop etc.)

The receiving process wakes up again after 10-30 seconds, at which point the pasted text may have been received ... or not. After a first hiccup, pasting generally fails, and this includes copy-pasting from VM to host. Pasting in KWrite consistently takes 10s until the cursor returns without the clipboard content. RStudio behaves more catastrophically, sometimes killing the process is the only solution.

If one leaves the VM alone for some time, one again has the chance at a few successful copy-paste actions, then lockups occur again.

Restarting spice-vdagent (systemctl start spice-vdagentd) on the guest machine (not on the host where it does nothing apparently) interrupts a lockup and may give the occasion to perform a few copy-paste again. But that action is fraught with some risk as I had the whole GUI freeze at some point.

How to solve?

What should I be looking for?

I have used xclipboard on the host to see what goes through the clipboard. Nothing unexpected seen.


The VM has been given a lot of RAM (10GiB), which seems necessary as knitting even not-too-large knit files involving intensity maps will cause pandoc to run out of memory.

RStudio sometimes freezes for itself for a couple of seconds when I'm working in it, again without locking up the whole system. Feels as if swapping or garbage collection was kicking in but nothing is going on I/O or CPU wise. Annoying but survivable.

  • Still a problem with RStudio 1.2.5033 Feb 27 '20 at 12:15
  • Actually here is the thing: 1) Mark something in the editor 2) CTRL-C to put it on the clipboard 3) CTRL-V in RStudio to paste it 4) Nothing happens, RStudio seems to hang, waiting for something 5) Mark again in the editor 6) CTRL-C to put it on the clipboard 7) RStudio immediately notices that there is new content and the text appears in RStudio. Feb 27 '20 at 12:34
  • Sometimes the editor (In this case, "kate", external to RStudio) seems to get into a funk, with the cursor disappearing. You should have started RStudio from the command line and leave it running in the "foregroud". In that case, CTRL-Z to temporarily stop RStudio. "fg" brings the editor back to life. ACTUALLY, this doesn't even really help, one may have to restart spice-vdagentd: sudo systemctl restart spice-vdagentd, which may indicate that there are additional problems than just RStudio. Feb 27 '20 at 12:49
  • ... and it seems related to whether you "cut" something to the clipboard (problems ensue, paste hangs) or just "copy" (paste works). Feb 27 '20 at 12:58
  • Yes, it's not only RStudio. There are problems even if RStudio hasn't been started yet. Feb 27 '20 at 14:07

On the RStudio Community BB, the following idea was provided:

Setting environment variable RSTUDIO_NO_CLIPBOARD_MONITORING=1

For example:


The base of this is this bugfix on GitHub:

"allow users to disable X11 clipboard monitoring"

based on this issue:

"RStudio 1.1.419 hangs periodically"

where we find:

It looks like the culprit may be RStudio over-aggressively listening for changes to the clipboard. See:

#9 0x00000000005a2745 in rstudio::desktop::GwtCallback::onClipboardChanged(QClipboard::Mode) ()

We do this to support the global mouse selection, but perhaps this is being done over-aggressively or we're handling clipboard notifications that we should be ignoring.

Performing the above improves response time but does not improve reliable copy-pasting.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.