After reconnecting the container with RDP, then sound and clipboard not working anymore!

[harcokuppens]

Everything works fine on first connect with RDP.
When I close the lid of my laptop the remote desktop connection is closed.
I can then just reconnect the RDP connection, however then everything works fine except that the clipboard and sound are not working anymore.

I investigated the problem, and pulseaudio seems to work fine. The sound controls shows the xrdp output working just fine with the sound meters fluctuating.
After deep investigation it seems that the 'xrdp-chansrv' process gets in a 'defunct' mode if the remote desktop connection gets broken.

 # ps -ef | grep defunc
 ubuntu        42      38  0 12:42 pts/0    00:00:00 [xrdp-chansrv] <defunct>

The documentation says:

      src: https://manpages.ubuntu.com/manpages/bionic/man8/xrdp-chansrv.8.html

       xrdp-chansrv  is  the  xrdp  channel  server, which manages the Remote Desktop Protocol
       (RDP) sub-channels.  This program is only forked internally by xrdp-sesman.
       Currently xrdp-chansrv knows about the following channels:

       cliprdr
              Clipboard Redirection

       rdpsnd Remote Desktop Protocol Sound

       rdpdr  Remote Desktop Protocol Device Redirection

       rail   Remote Applications Integrated Locally

       drdynvc
              Dynamic Virtual Channel

Because both sound and the clipboard are not working seems to be caused that "xrdp-chansrv" is defunct.

I tried several ways to recover "xrdp-chansrv" but nothing helped. This process seems to be launched internally by xrdp and you have no control over it. Killing it also doesn't solve the problem, because it just gets relaunched 'defunct' again.

I tried to get more info about why "xrdp-chansrv" gets defunct, maybe I could remove the cause to fix the problem.
I found in the log:

   /home/ubuntu/.local/share/xrdp/xrdp-chansrv.10.log
    [20230511-11:01:54] [CORE ] main: app started pid 42(0x0000002a)
    [20230511-11:01:54] [INFO ] main: DISPLAY env var set to :10.0
    [20230511-11:01:54] [INFO ] main: using DISPLAY 10
    [20230511-11:01:54] [INFO ] channel_thread_loop: thread start
    [20230511-11:01:54] [INFO ] Socket 12: AF_UNIX connection received

 <reconnect rdp>

    [20230511-11:08:51] [INFO ] Socket 15: AF_UNIX connection received
    [20230511-11:12:36] [INFO ] channel_thread_loop: trans_check_wait_objs error resetting

Seems that he tries to open a different socket...15 instead of 12 .. would that be the cause?
However, I have no way to configure 'xrdp-chansrv' to point it to the right socket?
Online I already found a request to let end-users relaunch the 'xrdp-chansrv' process themselves, but nothing implemented yet.
See: neutrinolabs/xrdp#1259

The only workaround is after reconnect to logout from the XFCE session and let it remember which programs you had open. Then the remote desktop connection gets closed. Then reopen the remote desktop connection, and you get a full new session with the XFCE desktop restarted and 'xrdp-chansrv' restarted and working again. This way you do not have to restart the container.

So It seems to be a problem with 'xrdp-chansrv' which people of the xrdp project could maybe fix in the future...
I google around and say more people struggling with the same kind of problem, however no fix found.

Do you have an idea?

At least I have a small workaround to continue working in the container with sound and clipboard restarted.

technical note: I'm using a Macbook pro with M1 processor, and using the latest version of the "Microsoft Remote Desktop" application.

[harcokuppens]

Good news I found a fix for the RDP reconnect problem which also makes reconnecting much faster!

I did dig more into defunct, and it seems that when the parent process of the defunct process is stopped it becomes
a child of the 'init' process with PID 1, which has the task to remove all defunct children it becomes the parent of.
But as long the parent process is running it stays there to allow the parent process to read its child's exit status.
The parent process should notice that the child process is defunct and remove it, and restart it.
But that is outside of our control, the xrdp process should do that, but it clearly doesn't which is also a bug in xrdp. The people who wrote xrdp should anticipate that sometimes a child process crashes by monitoring it, and restarting it when it does.

However, I noticed that when xrdp-chansrv became defunct and I started a new xrdp-chansrv in the container myself
then on restart of the RDP connection suddenly the sound worked again! So somehow this new xrdp-chansrv process gets picked up by xrdp on a new client connection.
I also noticed that xrdp allows you to execute some code in /etc/xrdp/reconnectwm.sh on a reconnect of the session.
So I finally found a fix with the following patch code:

 echo 'DISPLAY=:10.0 /sbin/xrdp-chansrv &' >> /etc/xrdp/reconnectwm.sh

Now on each reconnect a new xrdp-chansrv is launched in the background, and it fixed the problem!

But if we reconnect several times do we then not get multiple defunct processes?
No! First note that when the /etc/xrdp/reconnectwm.sh script finishes then its parent becomes PID 1, which is "bash /usr/bin/entrypoint, and not in an 'init' process like in linux/unix.
However I found out when the newly connected remote desktop connection is closed, then the newly started 'xrpd-chansrv' process still gets nicely closed. Why became clear to me after reading https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/. The new process became a child of 'sh', and 'sh' always cleans up its children when they become defunct.

To show what happens:

Initially no xrdp-chansrv is run until a session connects to xrdp.
So when the first RDP session is started then xrdp starts a xrdp-chansrv process.

    $ ps aux |grep chan
    ubuntu      50  0.0  0.0      0     0 pts/0    Z    10:13   0:00 [xrdp-chansrv] 

After first close RDP the chansrv started by xrdp gets defunct and not cleaned up.

    $ ps aux |grep chan
    ubuntu      50  0.0  0.0      0     0 pts/0    Z    10:13   0:00 [xrdp-chansrv] <defunct>

After reopening RDP in /etc/xrdp/reconnectwm.sh we start a new /sbin/xrdp-chansrv process

    $ ps aux |grep chan
    ubuntu      50  0.0  0.0      0     0 pts/0    Z    10:13   0:00 [xrdp-chansrv] <defunct>
    ubuntu    1219  0.7  0.0  86672  3308 pts/0    Sl   10:38   0:00 /sbin/xrdp-chansrv

After closing RDP again we see the newly started  xrdp-chansrv] is closed

    $ ps aux |grep chan
    ubuntu      50  0.0  0.0      0     0 pts/0    Z    10:13   0:00 [xrdp-chansrv] <defunct>

So the original defunct process stays, but the newly created 'xrdp-chansrv' processes are nicely cleaned up each time after a disconnect. GREAT!

Finally, I must remark then without this fix it also took long to reconnect with a black screen for many seconds, but with this fix the reconnect is almost immediately. So somehow a not working xrdp-chansrv process also slowed down the reconnects considerably.
So we fixed the clipboard and sound problem after reconnecting, and the reconnects are now always fast! GREAT!

In the case, the problem gets fixed by rdp in the future I only start a new xrdp-chansrv process when I discover it is defunct.

So the fix becomes a single command we should include in the Dockerfile:

echo 'if ps -e -o cmd | grep "\[xrdp-chansrv\] <defunct>"; then DISPLAY=:10.0 /sbin/xrdp-chansrv & fi' >> /etc/xrdp/reconnectwm.sh

The DISPLAY variable is hard coded to 10 ... I think that is the default always chosen by xrdp.

I created a patched version of the Dockerfile which contains this fix. Note however that I had to change the used ubuntu TAG from LATEST to 20.04 explicitly because the docker build gave errors for the current LATEST.

Finally, I discovered that I can pause the docker container and the RDP connection stays alive but frozen. When I resume the docker container the RDP session just continues without a problem. I can even close the RDP session when the docker container is paused, and reconnect the RDP session after the container is resumed.

[zhztheplayer]

Both this image and the one from another repo have this problem.

[zhztheplayer]

Tried with the fix and it worked perfectly so far. Thanks for sharing @harcokuppens !