Why can't I run multiple sessions for single user on CentOS Stream 8 & 9?

[zhenrong-wang]

Hi XRDP dev team,

I use XRDP for cloud development. After I upgrade my OS from CentOS 7.9 to CentOS Stream 8 & 9, I found XRDP (Version 0.9.17) behaves differently on CentOS 7.x (refer as CentOS7) and CentOS Stream 8&9 (refer as CentOS Stream). For any specific user, here are the differences:

CentOS 7: I can start different XRDP sessions with isolated desktop environments for a single user. For example, as root, I can start one XRDP session with 16 bpp, log in to my server, and keep it logged in; meanwhile, I can modify the color to 32 bpp and log in to my server. The 2 sessions coexist and work without any conflict. This feature gives users more freedom to start and manage his/her sessions, but the drawback is that a single user can initiate several Xvnc sessions, and some of them might be useless. For my workload, this feature is very good and convinient.

CentOS Stream: I cannot run multiple sessions concurrently as described above. Only one session works; if I DO want to start another session with a different configuration (for example, switch the color depth bpp), I MUST LOG OUT of the current session ( "Close" doesn't work, it will leave the session alive and block all the other sessions) and start the new session. If I don't LOG OUT, the new sessions will be a black screen; an even more complicated phenomenon is, that the new sessions interfere with the previous sessions:

• If I keep 2 sessions with defferent configurations open, the original one works, and the new one will show a black screen;
• If I do desktop operations on the original session, for example, right click on the desktop & Open in Terminal, the window Terminal will go to the new session. This is abnormal because the 2 sessions are supposed to be isolated (because I started them with different configurations).

I have no idea why the differences occur. Looking forward to your reply.

[zhenrong-wang]

Here are my logs of sesman:

[20220716-10:10:03] [INFO ] starting Xvnc session...
[20220716-10:10:03] [INFO ] Starting session: session_pid 102728, display :10.0, width 1808, height 976, bpp 16, client ip 183.192.231.10:21348 - socket: 12, user name root
[20220716-10:10:03] [INFO ] [session start] (display 10): calling auth_start_session from pid 102728
[20220716-10:10:03] [ERROR] sesman_data_in: scp_process_msg failed
[20220716-10:10:03] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220716-10:10:03] [INFO ] Starting X server on display 10: Xvnc :10 -auth .Xauthority -geometry 1808x976 -depth 16 -rfbauth /root/.vnc/sesman_passwd-root@master:10 -bs -nolisten tcp -localhost -dpi 96 -SecurityTypes None
[20220716-10:10:03] [INFO ] Found X server running at /tmp/.X11-unix/X10
[20220716-10:10:03] [INFO ] Found X server running at /tmp/.X11-unix/X10
[20220716-10:10:03] [INFO ] Found X server running at /tmp/.X11-unix/X10
[20220716-10:10:03] [INFO ] Session started successfully for user root on display 10
[20220716-10:10:03] [INFO ] Starting the xrdp channel server for display 10
[20220716-10:10:03] [INFO ] Starting the default window manager on display 10: /usr/libexec/xrdp/startwm-bash.sh
[20220716-10:10:03] [INFO ] Session in progress on display 10, waiting until the window manager (pid 102729) exits to end the session
[20220716-10:10:27] [INFO ] Socket 8: AF_INET connection received from 127.0.0.1 port 37514
[20220716-10:10:27] [INFO ] Terminal Server Users group is disabled, allowing authentication
[20220716-10:10:27] [INFO ] ++ created session (access granted): username root, ip 183.192.231.10:21376 - socket: 12
[20220716-10:10:27] [INFO ] starting Xvnc session...
[20220716-10:10:27] [INFO ] Starting session: session_pid 103512, display :11.0, width 640, height 480, bpp 32, client ip 183.192.231.10:21376 - socket: 12, user name root
[20220716-10:10:27] [INFO ] [session start] (display 11): calling auth_start_session from pid 103512
[20220716-10:10:27] [ERROR] sesman_data_in: scp_process_msg failed
[20220716-10:10:27] [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
[20220716-10:10:27] [INFO ] Starting X server on display 11: Xvnc :11 -auth .Xauthority -geometry 640x480 -depth 32 -rfbauth /root/.vnc/sesman_passwd-root@master:11 -bs -nolisten tcp -localhost -dpi 96 -SecurityTypes None
[20220716-10:10:27] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220716-10:10:27] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220716-10:10:27] [INFO ] Found X server running at /tmp/.X11-unix/X11
[20220716-10:10:27] [INFO ] Session started successfully for user root on display 11
[20220716-10:10:27] [INFO ] Starting the xrdp channel server for display 11
[20220716-10:10:27] [INFO ] Starting the default window manager on display 11: /usr/libexec/xrdp/startwm-bash.sh
[20220716-10:10:27] [INFO ] Session in progress on display 11, waiting until the window manager (pid 103513) exits to end the session

1. Do the errors matter?
2. From the log, It seems X server on 10 and 11 are working, but actually, only the one on display 10 works, the one on display 11 shows a black screen. And If I call out the Terminal window (or the Files window) on display 10, the window will be shown on the black screen of display 11. This really confuses me. It seems the Terminal window (or the Files window) is incorrectly redirected to display 11 (the black screen).

My Desktop Env:

On CentOS7: Gnome (yum -y groupinstall "GNOME Desktop" && systemctl set-default graphical.target)
On CentOS Stream: Gnome3 with gdm (yum -y groupinstall "Server with GUI" && systemctl enable gdm --now && systemctl set-default graphical.target)

Thanks a lot!

[matt335672]

Hi @zhenrong-wang

I've taken the liberty of converting this to a question, as this is a relatively common problem, not only with CentOS/Alma/Rocky, but also with Ubuntu.

The essential problem is that recent systemd-based Linux distros use systemd --user to manage a lot of desktop services. All of these services share an environment which you can see with systemctl --user show-environment.

When you log in to a desktop, this common environment is updated with a number of variables, including DISPLAY and DBUS_SESSION_BUS_ADDRESS.

The problem comes about as desktops assume that these two environment variables (and maybe others) are specific to the desktop instance. systemd --user breaks this assumption, and as a result, if you log in to two desktops at the same time on these systems, the two desktops will fall over each other, resulting in the problems you describe.

In short; the way systemd --user currently works does not allow the same user to have more than one desktop active at the same time.

This isn't restricted to xrdp - if you try to create a new session for a logged-in user using a virtual X server like Xvnc, you will encounter the same problems.

If you use a systemd-free distro, or FreeBSD you will find xrdp works fine.

CentOS 7 is not immune to this either - in a few situations you will find it's a bit broken. This is from memory a few years back so I may have the details wrong, but if you

• log in to a CentOS 7 system on the console
• log in over xrdp on the same system
• Plug a USB stick in on the console
• Set up a terminal with the default directory in the USB stick home directory
• Right-click on the USB stick on the console file manager and select remove

you will get a prompt telling you the stick can't be unmounted, but it will be in the xrdp session rather than on the console.

Does that make sense?

[zhenrong-wang]

Hi Matt,

Thanks a lot for your detailed reply. I think that's why when I google "XRDP black screen", I can always get some workaround methods to modify the startwm.sh with

unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR

before executing X11/Xsession. (See the link here https://c-nergy.be/blog/?p=16698)

I also tried this workaround, but unfortunately, I failed with XRDP 0.9.17 - 0.9.19 on CentOS Stream 8~9:

When I unset these 2 environment variables at the beginning of the startwm.sh, I did successfully get 2 XRDP sessions with different configurations (color depth and resolution), but all the 2 sessions crashed after I do any desktop operations (single click on the terminal icon, for example).

I also tried Xfce4 desktop environment, and replaced gdm wth lighdm, but still got the same problem.

However, I've been using CentOS 7.6 & 7.9 with GNOME for heavy GUI workloads - multiple windows and applications - for more than 1 year, and the problem never happened to me. I often use the same user to start different XRDP sessions with different configurations simultaneously, and no conflicts among sessions were found.

I'd suggest you do a quick test on CentOS 7.6 or 7.9 too, if possible.

Thanks!
Zhenrong

[matt335672]

As I said, there are only a few edge cases where CentOS 7.x doesn't quite do what you expect. On the whole it works fine when used in this manner.

For CentOS/Rocky/Alma 8/9, you'll need to make changes to the way you work. if you're lucky you might be able to get something working with a non-GNOME desktop (e.g. XFCE), but I wouldn't rely on it working after a minor release upgrade.

[zhenrong-wang]

Thanks a lot!

From this discussion, I think the root cause is clear - the OS enhanced the restriction to multi-sessions. Well, after all, this is not out of my expectation, it helps users avoid session managements (sometimes I may create some desktops and leave them there as 'zombie sessions'), although we lost some freedom.

Thanks again and hope more XRDP users see this discussion and stop trying those workarounds.

[zhenrong-wang]

Hi there,

After months, I finally found a good way to avoid the problems described above. Here is my practice:

1. Install xrdp using yum.
2. Edit the /etc/xrdp/xrdp.ini:

uncomment the line: ; (1 = ExtendedDesktopSize) by deleting the ';' at the beginning
uncomment the line: #xserverbpp=24 by deleting the '#' at the beginning

3. Restart the xrdp service: sudo systemctl restart xrdp

After the modification, no extra sessions will be created when you change the size or color depth from your RDP client. Therefore, no conflict will occur when you change the device you are using. For example,

1. You log in with Microsoft RDP client by using 1980*1020 and 32 bpp first, and then (without logging out)
2. You log in with 800*600 and 15 bpp

The xrdp service will update the original session from 1980 * 1020 to 800 * 600; the bpp remains 24 and ignore the client bpp setting. Since there is no extra session, the remote desktop works quite well. The dysfunction described in my original post is well avoided.

Hope my practice helps more xrdp users.

Zhenrong WANG @ Shanghai HPC-NOW Technologies Co., Ltd
[email protected]

[issuefiler]

xrdp/xrdp/xrdp.ini.in

Lines 232 to 258 in d71ec3f

	; Some session types such as Xorg and Xvnc start a display server.
	; Startup command-line parameters for the display server are configured
	; in sesman.ini. See and configure also sesman.ini.
	[Xorg]
	name=Xorg
	lib=libxup.@lib_extension@
	username=ask
	password=ask
	port=-1
	code=20
	[Xvnc]
	name=Xvnc
	lib=libvnc.@lib_extension@
	username=ask
	password=ask
	ip=127.0.0.1
	port=-1
	#xserverbpp=24
	#delay_ms=2000
	; Disable requested encodings to support buggy VNC servers
	; (1 = ExtendedDesktopSize)
	#disabled_encodings_mask=0
	; Use this to connect to a chansrv instance created outside of sesman
	; (e.g. as part of an x11vnc console session). Replace '0' with the
	; display number of the session
	#chansrvport=DISPLAY(0)

Apparently it’s configuration under the [Xvnc] session type. Did you use Xvnc or Xorg when connecting?

[zhenrong-wang]

Yes, I used Xvnc (tigervnc server) as a back end.