GNOME xrdp session sometimes freezes on reconnect

[nobias]

On several different installations of Ubuntu 20.04 (both VMs and non-virtualized installs), I keep hearing from several users (but not some other users) that their GNOME desktops sometimes freeze when they reconnect to pre-existing xrdp sessions. One user uses MS Remote Desktop from a Mac to connect, another one uses MS Remote Desktop from Win 10. Upon connect, they can move their mouse cursor but not click on anything. Sometimes the end up with a black screen after a while. This can happen after dozens of successful reconnects.

I have found this issue very hard to debug, I'm not seeing any relevant error messages in xrdp.log xrdp-sesman.log (both say that the reconnection attempts succeeded, the failed attempts look just like the successful ones) or ~/.xorgxrdp.XX.log, and I couldn't pinpoint any pattern in what the users had been doing / running. I've been seeing this issue on previous versions of Ubuntu, too, and it has survived all upgrades since 18.04. These machines are all joined into an AD domain, but authentication seems to be successful: xrdp reports that the sessions get established just fine. So this might totally be a GNOME issue. I'm willing to hunt down this bug more systematically, but would need some pointers on that. Thanks!

Package: xrdp: Version: 0.9.12-1

Package: xorgxrdp Version: 1:0.2.12-1

Package: gnome Version: 1:3.30+2

In the logfiles, connection attempts by user myuser1 until 13:01 were successful, but from 16:21 on they were frozen. At 16:55 we killed all of this user's processes.

.xorgxrdp.xx.log: https://pastebin.com/P4d8PsxH xrdp-sesman.log: https://pastebin.com/PVcqR8Wk xrdp.log: https://pastebin.com/WpZEWi2Y

[matt335672]

I saw something similar some time ago when I was running as sysadmin for a group of developers (also running as part of an AD domain).

It turned out to be an application the developers were running had made a mouse grab, and as a result the mouse buttons could not be used by anything else. It might have been Eclipse, but it's some time ago so I can't be certain. You could try logging in over ssh, setting DISPLAY and running something which makes a mouse grab like xwininfo. That might tell you if this is the problem.

X11 doesn't log things like this, so we ended up killing X11 applications one-by-one until we found the culprit.

Hope that's useful.

[derekschrock]

Possible this is related. https://github.com/neutrinolabs/xrdp/issues/1590

[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?

[nobias]

Thanks for the hint. I definitely disabled all screen locks, screensavers, and power saving options in my GNOME3, but the issue persists.

[stefanuhrig]

I had the same issue and I found the following entries in the system log that were written while the session was disconnected:

xrdp[36752]: [ERROR] xrdp_sec_recv: xrdp_mcs_recv failed
xrdp[36752]: [ERROR] xrdp_rdp_recv: xrdp_sec_recv failed
xrdp[36752]: [ERROR] libxrdp_process_data: xrdp_rdp_recv failed
xrdp[36752]: [ERROR] xrdp_process_data_in: xrdp_process_loop failed
xrdp[36752]: [ERROR] SSL_write: I/O error
xrdp[36752]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
xrdp[36752]: [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed

It appears that a connection on the server was idle for too long and therefore was terminated. I could solve the issue by adding the following options to my /etc/ssh/sshd_config:

ClientAliveInterval 300
ClientAliveCountMax 1152

They tell the SSH daemon to send a keep-alive packet every 5 minutes for at most 1152 times (which equals 4 days in total).

[matt335672]

The SSL library used by xrdp does not use /etc/ssh/sshd_config. I can't explain why editing this file should have any effect on xrdp.

[stefanuhrig]

Okay, then it might only have been a coincidence and something different fixed the issue on my system. I'll remove the entries from sshd_config again and I'll check if I'm running in this issue again afterwards.

[stefanuhrig]

@matt335672 is right. I just was lucky not to run into the issue for several days, but it has happened again although I've not removed my changes to sshd_config yet...

[kronenpj]

Experiencing this, with the same errors in xrdp-sesman.log, on Ubuntu 22.04, granted with a slightly older version - 0.9.17. Updating to current is in the plan for the near future.

[metalefty]

I don't think @stefanuhrig 's issue is not the same with the original post because this log is not recorded in the @nobias 's log. I think it should be reported as separate issue.

xrdp[36752]: [ERROR] xrdp_sec_recv: xrdp_mcs_recv failed
xrdp[36752]: [ERROR] xrdp_rdp_recv: xrdp_sec_recv failed
xrdp[36752]: [ERROR] libxrdp_process_data: xrdp_rdp_recv failed
xrdp[36752]: [ERROR] xrdp_process_data_in: xrdp_process_loop failed
xrdp[36752]: [ERROR] SSL_write: I/O error
xrdp[36752]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
xrdp[36752]: [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed

Regarding @kronenpj 's issue, I don't see any errors in the @nobias 's xrdp-sesman.log. Should post the actual log instead the word "the same errors".