matt335672
commented
4 years ago Hi @Mikky83
Thanks for reporting this.
What platform are you on, or are you building from scratch?
Some of this should be sortable without any significant changes. For example, the logic for the chansrv log file path is:-
- If
CHANSRV_LOG_PATHis defined in the environment, use that. - Otherwise, if
XDG_DATA_HOMEis defined and exists, use$XDG_DATA_HOME/xrdp, creating the sub-directory if necessary. - Otherwise use
$HOME//.local/share/xrdp, creating sub-directories as necessary.
The intention is for each user to have a private directory for chansrv. This should not be shared.
coreypenford
ivzhh
SolidState214
Hi All, I've found many issues related with copy-paste functionality via xrdp. Following up all of those threads, I couldn't find a solution for my issue. So, I was able to track the issue in my case and find what is the root cause. I would like to share it here, it might help to somebody and I believe dev team could prevent the issue in the upcoming versions. When copy-paste functionality doesn't work, you will see the following in the logs:
[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...[DEBUG] Closed socket 18 (AF_UNIX)[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...[DEBUG] Closed socket 18 (AF_UNIX)[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...[DEBUG] Closed socket 18 (AF_UNIX)[ERROR] xrdp_mm_connect_chansrv: connect failed trying again...[ERROR] xrdp_mm_connect_chansrv: error in trans_connect chanAlso you will see that xrdp-chansrv service is in "defunct" state.
root cause in my case: Each user when connecting to xrdp creates chansrv.$number.log under /tmp. $number is the session number. When working with Xvnc you could find the session number after "Xvnc:" process line. If a user logout for some reason sometimes chansrv.$number.log under /tmp is not cleaned up. Same is happening when you restart the xrdp service or even when you restart the OS. When a new user connects with a session number which was previously closed by another user, then chansrv.$number.log under /tmp exists with the same name. log file is owned by another user. Normally xrdp-chansrv process cannot write to the log because of permission issue and automatically goes to defunct state. Solution is to remove old chansrv log files and make a new connection. xrdp-chansrv process works and copy-paste also works.
Dev team, please fix this behaviour. I would recommend to either create one common log file and set all users to write to it, or to remove old chansrv logs from /tmp after service restart. You can make it the same as for cleaning up the files under /tmp/.xrdp/. That one works fine except when X server crashes, but that's another topic :)