Description

The clipboard and shared drives are supported by a program called chansrv.

When a client is connected successfully to a session, the process connections look like this:-

erDiagram
   Client ||--|| xrdp : connected
   xrdp ||--|| "backend (X server)" : connected
   xrdp ||--|| chansrv : connected

When the client exits, the xrdp process also exits, leaving the backend and chansrv processes running. When another client connects to the same session, a new xrdp process is created. This connects to the session backend and chansrv processes.

If a second client tries to connect while the first client is connected, you end up with the following set of connections:-

erDiagram
   Client1 ||--|| xrdp1 : connected
   xrdp1 ||--|| backend : connected
   xrdp1 ||--|| chansrv : connected
   Client2 ||--|| xrdp2 : connected
   xrdp2 ||--|| backend : connected

There are a couple of problems with this:-

1. Although the backend may currently be shared, this is unlikely to work in the future.
2. The second connection has no access to chansrv, and to the shared drives and clipboard.

Symptoms

1. Shared drives and clipboard do not work.
2. The connection takes around 15 seconds longer than expected
3. xrdp.log contains messages looking like this:-

   [WARN ] xrdp_mm_chansrv_connect: connect failed trying again...
   

4. A process xrdp-chansrv is running as the current user.

Another possibility is that your xrdp-chansrv process has crashed. If you have an xrdp-chansrv process running as the current user marked as a zombie, please raise an issue for xrdp versions later than v0.9.12.

Circumstances

This most obvious circumstance is where you simply connect to a session before logging another client out. For example, you may be in the office one day, and the next day when you try to connect from home, the office connection is still active.

It also happens when for some reason the xrdp process does not see the client finish (in technical terms, the TCP FIN is lost). In this case the xrdp process becomes orphaned, and will continue to run even though no client is connected to it.

Solution

The solution is for the orphaned xrdp process to be killed by the xrdp session manager (xrdp-sesman) when a new connection is received.

We're working towards this solution, but it can't be retro-fitted to existing xrdp versions.

Workarounds

Use TCP keepalive

See issue #1188, and in particular, this post

Consider this workaround for users without sudo privileges, or for shared systems.

Kill the orphaned xrdp process

See discussion #2717 for the background to this.

Only consider this workaround if all of the following are true:-

• You are running as a user with sudo privileges.
• This is a single-user system

Create a script kill_xrdp.sh with the following contents:-

#!/bin/sh

# Script to kill all xrdp processes except the listener

# Username xrdp runs as:-
# - Debian/Ubuntu, etc : xrdp
# - Others : root
XRDP_USER=xrdp

if ! getent passwd "$XRDP_USER" >/dev/null; then
    echo "** xrdp user '$XRDP_USER' does not exist on this system" >&2
    exit 1
fi

pidlist=

for pid in `pgrep -u $XRDP_USER xrdp\$`; do
    ppid=`ps -o ppid= -p $pid` ; # Get parent pid
    if [ -z "$ppid" ]; then
        echo "** Can't get Parent PID of $pid" >&2
    elif [ $ppid -ne 1 ]; then
        pidlist="$pidlist $pid"
    fi
done

if [ -z "$pidlist" ]; then
    echo "** No xrdp sessions were found" >&2
    false
else
    echo "Killing PIDs :$pidlist"
    sudo -u $XRDP_USER kill $pidlist
fi

exit $?

Make sure the setting of XRDP_USER is correct for your system.

When the problem occurs, run the script. Enter your password if prompted. You will be disconnected. When you reconnect the clipboard and shared drives should be working again.