Replies: 3 comments 28 replies
-
|
Thanks for raising this, @djakubek Having just rebuilt my xrdp development rig, I'm seeing something similar on Ubuntu 24.04, but not in xrdp - I'm seeing it on the VM console using the QEMU QXL driver. Ubuntu 22.04 works fine in the same configuration. There seem to be a few people having similar issues (on the console) on 24.04 using Xorg. There are no obvious common factors between them that I can see, except using At this point I can't offer you a solution, but here are a few potential workarounds:-
Hope this helps a little. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Here are the logs you requested. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @djakubek For the log in question, I can't see there's much to be changed here. Are any of your users in the |
Beta Was this translation helpful? Give feedback.
25 replies
-
|
Hi @matt335672 I made changes that improved or solved my problem. I've been testing it in production for a few days now and it's fine and works really efficiently, it doesn't even interrupt my user sessions. the whole file looks like this: I was guided by the problem with [4.3] |
Beta Was this translation helpful? Give feedback.
-
|
That's interesting. I don't think GNOME will be expecting to be started in this way, but if it works for you that's great news. These lines probably aren't doing anything now, as the exec before will terminate the script. |
Beta Was this translation helpful? Give feedback.
-
|
As for the logs I sent you, I noticed that different users frequently receive the same display, in this case, 14.0, which seemed to be unintended behavior. At present, each user receives their own unique DISPLAY, which is not assigned to another user. |
Beta Was this translation helpful? Give feedback.
-
|
The display is assigned by sesman - changing that script won't change that. If you restart xrdp-sesman with active sessions this could happen. This is a known problem - see #800. Could that be what is happening? |
Beta Was this translation helpful? Give feedback.
-
I thought so too, but without it, it doesn't work at all. The remote desktop doesn't even reach the graphical environment. |
Beta Was this translation helpful? Give feedback.
-
|
Try running the script with tracing from the command line to see what exactly is happening:- |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Beta Was this translation helpful? Give feedback.
-
|
Interesting! These two lines don't appear to be doing anything then, apart from possibly causing a delay:- You can add the missing space in front of the |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have an installation of Ubuntu 24.04 LTS with the Gnome graphical interface in a VMware environment:
60 GB RAM
55 GB Disk
8 CPUs
The basic installation consists of standard packages without any tweaks: xrdp, dbus-x11. The server is used by approximately 30 users simultaneously, connected via RDP from Windows 10/11. The users are created using the useradd -m ... command. The issue is difficult to pinpoint. I've searched extensively and haven't found any solid solutions. The problem manifests randomly as a black screen with an active cursor, with no response to keyboard inputs like ENTER or ESC.
This issue occurs for a random user upon their first login after a server restart. Sometimes it's the first user, other times it may be the third or any other user. Out of 30 users, about 24 log in successfully. Occasionally, all users log in without issue. In the second scenario, when sessions are active and a user attempts to reconnect to their RDP session after some time, they again encounter the "Black Screen."
I handle the problem by identifying the session of the user who faces the "Black Screen" and terminate it using loginctl terminate-session . Re-logging into the same account usually resolves the issue, though sometimes I have to repeat the process twice in a row.
I tried removing all snapd packages from the system, which did not yield the expected results, although working with the desktop became more responsive, which is a plus for me. Currently, only the .deb package of the Chrome browser is installed.
xrdp version: 0.9.24
Dbus-daemon version: 1.14.10
In the file nano /etc/gdm3/custom.conf:
#Wayland=false is left by default without any impact on solving the issue.
I also attempted to add the variable to the file /etc/xrdp/startwm.sh --> export XDG_SESSION_TYPE=x11.
I’m out of ideas now. :(
I’m attaching the syslog logs.
Beta Was this translation helpful? Give feedback.
All reactions