frozen session for a period time on reconnect when syncing clipboard data with autocutsel

[derekschrock]

When using autocutsel to sync clipboard data with PRIMARY and CLIPBOARD buffers if last clipboard buffer was copied from the host (in turn synced to chansrv's CLIPBOARD) and the RDP session is disconnected, autocutsel will slowly increase in CPU and memory usage until a client reconnects. On reconnect it appears Xorg/chansrv process autocutsel requests.

If the time between disconnect and reconnect is too long there may be a noticeable freeze on reconnect until the RDP session becomes responsive.

From my understanding of autocutsel by default it polls the selection (CLIPBOARD default and PRIMARY if set) n buffer's every 500 ms then issues a series of Xt API calls that result in multiple callbacks. It appears that these API/callbacks might be requesting data from chansrv however during the idle period mentioned above chansrv is blocking waiting for a reconnect from a client.

On reconnect autocutsel's and chansrv's CPU usage will increase to ~100% each. Xorg CPU usage increases a marginal amount. The RDP session will be frozen for a period of time during this phase. Mouse clicks and keyboard actions are not seen.

On a LAN connection the freeze phase can last any where between 15-30 seconds However, on a WAN connection I've had non-scientific reports of 20+ minutes until RDP responded to clicks/keyboard.

This was noticed when leaving an RDP session disconnected overnight (~12 hours) however I believe if you create the poll time via a command line option you can reproduce this same senerio in a couple minutes instead having to wait half a day for the X calls to queue.

To reproduce in a quick manner I did the following with a fully updated centos7 with xrdp from EPEL using fvwm. I don't believe the window manager matters here. I've also reproduced this with FreeBSD as well.

• ssh to RDP server machine and run top sort by CPU usage
• Open RDP session with clipboard syncing enabled
• Open terminal and run autocutsel -v -p 1
  • This will sync the CLIPBOARD with the cut buffer
  • This will show high CPU usage. You can ignore that.
• Outside of the RDP session copy text.
• Go back to the RDP session
  • Be sure to not select any text.
  • This should have synced the host's clipboard to RDP
• Disconnect
• Remain disconnected for ~2-3 minutes if you're on a LAN connection.
• Reconnect
• See the RDP session is drawn however clicks and keyboard actions are not registering. This should be the case for ~15-30 seconds.
• If ssh'ed see top output showing autocutsel and sesman are around 100% each.
• Wait until RDP session is responsive
• Control-C autocutsel.

autocutsel ... -p 1 is not real world usage here just a means to reproduce the issue without having to wait. You should see the same issue with you used the default 500ms poll and waited 12 hours.

Attaching a debugger to autocutsel and putting a breakpoint in CheckBuffer you should be able to see it's running thru some clean up loop thats handling ~87000 procs. That number varies depending on the time between disconnect/reconnect.

If the above is correct is it possible for chansrv to process these requests while a client isn't connected or unown the CLIPBOARD selection on disconnect? This does not occur when the last selection didn't come from the host/chansrv (or when chansrv owns the selection?)

Is this something that would be best solved by Xorg or autocutsel if so then we can close this issue.

There were some discussions with @metalefty on gitter found here and here. He claims he has seen the same issue with parcellite. Also, this same issue might be manifesting itself by other means mentioned here.

[xpusostomos]

I'll put this here because it might be relevant, and it also might help anyone who lands here.

I was having this problem with xfce4. Whether the screen is black depends on whether its been idle for 10 minutes or more, and this is caused by the Xfce power manager. Go into the Xfce power manager and turn off, max out and disable all display and system time outs. Perhaps Gnome has a simliar feature?