XRDP doesn't cleanup user sessions on service restart, subsequent attempts to RDP to the system fail

[cobbr]

xrdp version

0.9.17

Detailed xrdp version, build options

$ xrdp --version
xrdp 0.9.17
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2020 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --enable-ipv6
      --enable-jpeg
      --enable-fuse
      --enable-rfxcodec
      --enable-opus
      --enable-painter
      --enable-vsock
      --build=x86_64-linux-gnu
      --prefix=/usr
      --includedir=${prefix}/include
      --mandir=${prefix}/share/man
      --infodir=${prefix}/share/info
      --sysconfdir=/etc
      --localstatedir=/var
      --disable-silent-rules
      --libdir=${prefix}/lib/x86_64-linux-gnu
      --libexecdir=${prefix}/lib/x86_64-linux-gnu
      --disable-maintainer-mode
      --disable-dependency-tracking
      --with-socketdir=/run/xrdp/sockdir
      build_alias=x86_64-linux-gnu
      CFLAGS=-g -O2 -ffile-prefix-map=/build/xrdp-asBei3/xrdp-0.9.17=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
      LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now -Wl,--as-needed
      CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 -Wno-error=deprecated-declarations
      PKG_CONFIG_PATH=/build/xrdp-asBei3/xrdp-0.9.17/pkgconfig

  Compiled with OpenSSL 3.0.2 15 Mar 2022

Operating system & version

Ubuntu 22.04

Installation method

dnf / apt / zypper / pkg / etc

Which backend do you use?

xorgrdp

What desktop environment do you use?

XFCE4

Environment xrdp running on

VM

What's your client?

Apache guacamole

Area(s) with issue?

No response

Steps to reproduce

1. RDP to system running xrdp as user "testuser1" (for example)
2. Restart the xrdp systemd service service xrdp restart
3. RDP again to system running xrdp as user "testuser1"

✔️ Expected Behavior

Expect to be able to reconnect via RDP to the system running XRDP as the same user

❌ Actual Behavior

Unable to connect via RDP to the system running xrdp until the system has been rebooted or processes running as "testuser1" are killed off.

Anything else?

I believe this has to do with the issue that typically arises if you try to RDP as user that is already connected at the console. Killing off the user process before reconnecting (pkill -U testuser1) fixes the issue.

But in this case, the user was never connected to the physical console, the original XRDP session was never cleaned up when the service restarted and now it's impossible to connect as the user again.

Service restarts are inevitable. In our case, the user runs some sort of apt package installs, which can cause various systemd services to restart, and are disconnected from their RDP session and are unable to reconnect without a reboot.

Is this expected behavior? Should XRDP cleanup/kill the Xsession when the service is restarted? Is there some configuration options or workaround to cleanup the session on service restart?

[matt335672]

Hi @cobbr

This is indeed a long-standing issue - see #800

There are two significant problems with v0.9.x of xrdp in this area:-

1. sesman stores an in-memory copy of active sessions. When sesman is restarted this information is lost and hence sesman cannot reconnect to them.
2. sesman uses SIGCHLD to know when a session exits. That means when sesman is restarted, it loses the capability to detect sessions exiting, even if it could re-establish a connection to them.

The good news is we've changed the architecture around sesman to make it possible to fix this (#1691). A process called sesexec now manages each session. The link between the two processes is no longer based in signals, but uses a file descriptor. When sesman goes away and comes back, sesexec will re-establish contact and allow sesman to restore its active session list.

The first stage of the architectural change is in devel builds It will will be released as part of v0.10.x which is in beta now. After this, we'll be able to get the plumbing in to fully fix this.

Workarounds:-

1. Don't restart sesman. Easy to say I know, but an apt update should only restart sesman if xrdp is updated, not any other packages. This is really rare on Ubuntu as they don't roll out feature upgrades for this package - only security updates. So although I broadly agree with your assertion that "service restarts are inevitable", it's not going to happen to xrdp that much.
2. Following on from 1), use package pinning to stop xrdp being updated by your users. You'll need to regularly check for security updates manually.
3. Another alternative is to add a script to be called from ExecStopPost= in the systemd unit for sesman (see systemd.service(5)) to clean up. It might seem attractive on the surface, but your options here with version 0.9.17 of xrdp are really limited as identifying xrdp processes is tricky.
   a) One option is to use a variation of pkill Xorg to kill all Xorg processes. This will only target xrdp processes if the console user is using Wayland.
   b) See whether loginctl identifies xrdp sessions. It may, or may not depending on your setup. The details are in No user session created with xrdp and pam_systemd_home account module #1684, but it's not an easy read.
   Either of these would need some testing however, so whether the time and disruption required to do that is worth it for you, I can't say.

Based on what you've told me, I'd say 2) is probably the simplest avenue for you to explore. If you've got pre-prod capability you can test it by installing an older version of 22.04 without updates, enabled, set the pinning up, and then run the update.

Is any of that useful to you?

[cobbr]

This is very informative and helpful @matt335672, thank you. I think I'll explore ExecStopPost