XRDP frozen/hung and crashed display.

[xDnixxy]

Our team is experiencing a frozen state with the XRDP. The issue only occurs when opening the GVIM editor with Verdi SLURM jobs.

No error/warning is showing when this is happening so I am not sure where to start in troubleshooting it. For the XRDP logs with chansrv, I tried to reconnect it, but the issue persisted. See below for reference:

XRDP logs:

[20240223-05:32:21] [INFO ] connecting to sesman on 127.0.0.1:3350
[20240223-05:32:21] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20240223-05:32:21] [INFO ] sesman connect ok
[20240223-05:32:21] [INFO ] sending login info to session manager. Please wait...
[20240223-05:32:22] [INFO ] xrdp_wm_log_msg: login failed for user gvenkatesh
[20240223-05:32:22] [INFO ] login failed for user gvenkatesh
[20240223-05:32:39] [INFO ] connecting to sesman on 127.0.0.1:3350
[20240223-05:32:39] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20240223-05:32:39] [INFO ] sesman connect ok
[20240223-05:32:39] [INFO ] sending login info to session manager. Please wait...
[20240223-05:32:39] [INFO ] xrdp_wm_log_msg: login failed for user gvenkatesh
[20240223-05:32:39] [INFO ] login failed for user gvenkatesh
[20240223-05:32:51] [INFO ] connecting to sesman on 127.0.0.1:3350
[20240223-05:32:52] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20240223-05:32:52] [INFO ] sesman connect ok
[20240223-05:32:52] [INFO ] sending login info to session manager. Please wait...
[20240223-05:32:52] [INFO ] xrdp_wm_log_msg: login successful for user gvenkatesh on display 59
[20240223-05:32:52] [INFO ] login successful for user gvenkatesh on display 59
[20240223-05:32:52] [INFO ] loaded module 'libvnc.so' ok, interface size 4064, version 4
[20240223-05:32:52] [INFO ] VNC started connecting
[20240223-05:32:52] [INFO ] VNC connecting to 127.0.0.1 5959
[20240223-05:32:52] [INFO ] VNC tcp connected
[20240223-05:32:52] [INFO ] VNC security level is 2 (1 = none, 2 = standard)
[20240223-05:32:52] [INFO ] VNC password ok
[20240223-05:32:52] [INFO ] VNC sending share flag
[20240223-05:32:52] [INFO ] VNC receiving server init
[20240223-05:32:52] [INFO ] VNC receiving pixel format
[20240223-05:32:52] [INFO ] VNC receiving name length
[20240223-05:32:52] [INFO ] VNC receiving name
[20240223-05:32:52] [INFO ] VNC sending pixel format
[20240223-05:32:52] [INFO ] VNC sending cursor
[20240223-05:32:52] [INFO ] VNC connection complete, connected ok
[20240223-05:32:52] [INFO ] VNC: Clipboard (if available) is provided by chansrv facility
[20240223-05:32:52] [INFO ] connected ok
[20240223-05:32:56] [WARN ] xrdp_mm_chansrv_connect: connect failed trying again...
[20240223-05:33:00] [WARN ] xrdp_mm_chansrv_connect: connect failed trying again...
[20240223-05:33:04] [WARN ] xrdp_mm_chansrv_connect: connect failed trying again...
[20240223-05:33:08] [WARN ] xrdp_mm_chansrv_connect: connect failed trying again...
[20240223-05:33:08] [ERROR] xrdp_mm_chansrv_connect: error in trans_connect chan
[20240223-05:33:08] [INFO ] Layout from OldLayout (geom=1440x900 #screens=1) : 1804289383:(1440x900+0+0)

Sesman logs:

[20240223-05:32:52] [ERROR] sesman_data_in: scp_process_msg failed
[20240223-05:32:52] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20240223-05:32:52] [INFO ] Starting session reconnection script on display 59: /usr/libexec/xrdp/reconnectwm.sh
[20240223-05:32:52] [INFO ] Process 1734773 has exited

.local/share/xrdp/ logs:

[20240223-04:02:50] [INFO ] Socket 14: AF_UNIX connection received
[20240223-04:02:50] [INFO ] sound_process_output_format:
[20240223-04:02:50] [INFO ] wFormatNo 0
[20240223-04:02:50] [INFO ] wFormatTag WAVE_FORMAT_PCM
[20240223-04:02:50] [INFO ] nChannels 2
[20240223-04:02:50] [INFO ] nSamplesPerSec 44100
[20240223-04:02:50] [INFO ] nAvgBytesPerSec 176400
[20240223-04:02:50] [INFO ] nBlockAlign 4
[20240223-04:02:50] [INFO ] wBitsPerSample 16
[20240223-04:02:50] [INFO ] cbSize 0
[20240223-04:02:50] [INFO ] sound_process_output_format:
[20240223-04:02:50] [INFO ] wFormatNo 1
[20240223-04:02:50] [INFO ] wFormatTag WAVE_FORMAT_PCM
[20240223-04:02:50] [INFO ] nChannels 2
[20240223-04:02:50] [INFO ] nSamplesPerSec 22050
[20240223-04:02:50] [INFO ] nAvgBytesPerSec 88200
[20240223-04:02:50] [INFO ] nBlockAlign 4
[20240223-04:02:50] [INFO ] wBitsPerSample 16
[20240223-04:02:50] [INFO ] cbSize 0
[20240223-04:02:52] [INFO ] sound_process_training: round trip time 2015
[20240223-04:02:52] [INFO ] Detected remote smartcard 'SCARD'

Can someone experience the same case? The only workaround we can perform is to restart the XVNC PID or terminate the VERDI SLURMS, but sometimes it doesn't work.

I would greatly appreciate any input you can provide. Thanks in advance!

[matt335672]

This looks like a VNC server issue. When the VNC server is used as a back-end, xrdp just acts as a protocol converter, so it would struggle to produce a screen like that (I think).

You don't say what system you're running on, but if you're using the VNC backend I'd guess at RHEL or a derivative. This uses tigervnc as the VNC server by default.

For starters, try changing the colour depth the client is using for VNC. See #2945 for a potentially similar issue with tigervnc.

If that doesn't work, install the xorgxrdp package and try that. This will involve a few trade-offs but may give more information.

[xDnixxy]

@matt335672 I appreciate your prompt response.

We are currently using the Rhel8 Linux System, as you mentioned. I previously attempted to modify the color depth, but unfortunately, the issue persists. In our setup, XVNC is required for SLURM connection, and utilizing XorgXrdp is not feasible. However, we will still attempt to implement it. Thank you for suggesting it.

Additionally, as a workaround due to the instability of XRDP, we have separately installed tigervnc on our server. However, we preferred XRDP for its lower resource usage. If you have any recommendations or suggestions in this regard, much appreaciated.

Furthermore, additional question for chansrv's. Is there a way to restart them from the terminal? I am looking for related threads but none of them work. Just wanted some verification.

Thank you so much!

[matt335672]

I'm a bit confused by this statement of yours:-

...we have separately installed tigervnc on our server. However, we preferred XRDP for its lower resource usage. If you have any recommendations or suggestions in this regard, much appreaciated.

xrdp uses a VNC server as its backend, as you can tell from the logs. Normally this is tigervnc anyway, so I can't see how xrdp can provide lower resource usage. Also, are you saying that tigervnc is working and xrdp isn't?

To restart chansrv:-

1. Start a terminal window in the xrdp session.
2. pkill chansrv (if it isn't dead already)
3. fusermount -u ~/thinclient_drives
4. xrdp-chansrv

chansrv shouldn't be crashing. What is happening to it exactly?

[xDnixxy]

Apologies for the confusion, and thanks for the clarifications. For the hung/display issues, I'll test it for now as we can't restart the XRDP service at a crucial time like this as we have running jobs atm.

chansrv shouldn't be crashing. What is happening to it exactly?

• We are having trouble with the copy/paste from Windows to XRDP. This happens when the XRDP has a sudden disconnection with the internet.
• We manually modified the /usr/libexec/xrdp/reconnectwm.sh directory file and added the display (DISPLAY=:13.0 /sbin/xrdp-chansrv &).
  The downside is, we need to reopen the RDP client to reconnect the chansrv.

So here, I just wanted to know if there will be a way to reconnect it automatically without restarting the RDP client manually.

on the other side:
I am having the below error when trying to unmount the thinclient_drives. See below:
fusermount: failed to unmount /home/username/thinclient_drives: Invalid argument

[matt335672]

The fusermount error possibly means that the thinclient_drives directory wasn't mounted anyway. You can ignore that.

Once you're restarted chansrv, you have to reconnect the client to get it working I'm afraid. The connection path is xrdp -> chansrv and not the other way round, as it's easier to make that secure.

[xDnixxy]

Hi @matt335672,

I appreciate you for providing all the clarifications. I have one final question: Occasionally, we encounter difficulties logging in with XRDP. We have to make multiple attempts, around 3 to 8 times, before a successful login. Do you have any insights into why this might be happening??

Thanks in advance.

[matt335672]

Not really.

If you're having trouble logging in:-

1. Check xrdp-sesman.log and your system audit.log for messages related to PAM authentication.
2. Try typing some password characters in the username field on the login box to see what xrdp thinks the keyboard is generating.