Generally a black screen indicates you are still "logged in" to your previous session.
How are you disconnecting from the first session?
| Git Clone URL: | https://aur.archlinux.org/xrdp.git (read-only, click to copy) |
|---|---|
| Package Base: | xrdp |
| Description: | An open source remote desktop protocol (RDP) server |
| Upstream URL: | https://github.com/neutrinolabs/xrdp |
| Keywords: | rdp vnc xdrp |
| Licenses: | Apache-2.0 |
| Submitter: | None |
| Maintainer: | Abzie |
| Last Packager: | Abzie |
| Votes: | 152 |
| Popularity: | 0.54 |
| First Submitted: | 2008-01-15 15:02 (UTC) |
| Last Updated: | 2026-04-19 11:59 (UTC) |
« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 .. 20 Next › Last »
Generally a black screen indicates you are still "logged in" to your previous session.
How are you disconnecting from the first session?
Anyone else run into issues logging back into a previously active xrdp session following a restart of the service?
I had some applications open on my xrdp desktop and then logged out of xrdp, restarted the service, and was unable to log in again: plasma would start to load and then I'd get the generic black screen with xorg's massive black X cursor. All my googling tells me xrdp is supposed to clean up sessions when restarting.
To resolve, I went through all plasma and xorg processes and killed them (many were in a defunct state). Then when I tried to log in via xrdp, plasma started up just fine.
I'm using /usr/lib/plasma-dbus-run-session-if-needed startplasma-x11 in the .xinitrc if that helps.
As described earlier in comments in Manjaro the /usr/bin/Xorg is a script that decides to use /usr/lib/Xorg or /usr/lib/Xorg.wrapper. But when using /usr/lib/Xorg.wrapper you have to allow anybody to start X (Add allowed_users=anybody to /etc/X11/Xwrapper.config). Maybe there are more things to do.
The most easy way is to set param=/usr/lib/Xorg in sesman.ini. This setting will be saved, even with new versions of xrdp, since sesman.ini isn't overwritten by default.
Remember the default configuration is good if you are extendig a simple desktop system with xrdp. But when using a real xrdp server with multiple users and no local desktop its better to create a global xorg.conf https://aur.archlinux.org/packages/xrdp?O=60#comment-762246
Unable to login after upgrading xrdp to 0.9.21.1, here is part of my xrdp-sesman log.
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [INFO ] Socket 12: AF_INET6 connection received from ::1 port 53686
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: pam_systemd_home(xrdp-sesman:auth): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found. Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [INFO ] Terminal Server Users group is disabled, allowing authentication
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [INFO ] ++ created session (access granted): username peng, ip ::1:51522 - socket: 12 Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [INFO ] starting Xorg session...
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [INFO ] Starting session: session_pid 2596, display :10.0, width 1920, height 1080, bpp 24, client ip ::1:51522 - socket: 12, user name peng
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2596]: [INFO ] [session start] (display 10): calling auth_start_session from pid 2596 Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [ERROR] sesman_data_in: scp_process_msg failed
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2596]: pam_unix(xrdp-sesman:session): session opened for user peng(uid=1000) by (uid=0) Dec 20 10:53:13 NukeDesktop xrdp-sesman[2596]: pam_systemd(xrdp-sesman:session): Failed to create session: No child processes
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2109]: [ERROR] sesman_main_loop: trans_check_wait_objs failed, removing trans
Dec 20 10:53:13 NukeDesktop xrdp-sesman[2598]: [INFO ] Starting X server on display 10: /usr/bin/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -l
ogfile .xorgxrdp.%s.log
Dec 20 10:53:22 NukeDesktop xrdp-sesman[2596]: [WARN ] Timed out waiting for X server on display 10 to startup
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: [INFO ] Session started successfully for user peng on display 10
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2602]: [INFO ] Starting the xrdp channel server for display 10
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: [INFO ] Session in progress on display 10, waiting until the window manager (pid 2597) exits to end the session
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2597]: [WARN ] Timed out waiting for X server on display 10 to startup
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2597]: [ERROR] There is no X server active on display 10
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2597]: [ERROR] A fatal error has occurred attempting to start the window manager on display 10, aborting connection
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: [WARN ] Window manager (pid 2597, display 10) exited quickly (0 secs). This could indicate a window manager config problem
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: [INFO ] Calling auth_stop_session and auth_end from pid 2596
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: pam_unix(xrdp-sesman:session): session closed for user peng
Dec 20 10:53:23 NukeDesktop xrdp-sesman[2596]: [INFO ] Terminating X server (pid 2598) on display 10
I have noticed that this update has some changes in /etc/xrdp/sesman.ini and the path to Xorg executable is changed from param=/usr/lib/Xorg to param=Xorg (which results in /usr/bin/Xorg). When I tried to change the path back to /usr/lib/Xorg and restart xrdp.service, I was able to login to my desktop as before.
What is the difference between /usr/lib/Xorg and /usr/bin/Xorg? Or is something wrong with my PATH?
I am still too new to Arch and AUR to know how to make a pull request to the actual xrdp AUR package. I apologize for my ignorance but hope that someone can use the info below to upgrade their xrdp implementation to 0.9.21.1 - the latest release as of today.
I have updated the PKGBUILD and arch-config.diff from 0.9.19 to 0.9.21.1. They are contained in the following gists:
PKGBUILD - https://gist.github.com/lbe/80b17cc2c9acb6a357ad64b2223db491
arch-conf.diff - https://gist.github.com/lbe/3c2658466175f9ff8c541566e59ffc0d
Please note that this PKGBUILD does NOT contain a dependency upon tigervnc.
If you wish to use tigervnc, you will need to install it separately.
To use these:
git clone https://aur.archlinux.org/xrdp.git
Replace PKGBUILD with - https://gist.github.com/lbe/80b17cc2c9acb6a357ad64b2223db491
Replace arch-config.diff with - https://gist.github.com/lbe/3c2658466175f9ff8c541566e59ffc0d
Run make -si - This will sync the xrdp source and build the install package and then install the same if the build is successful
HTH, lbe
0.9.21 was released with a bunch of security fixes.
Here's my diff to simply update this package to 0.9.20: https://0x0.st/okCa.diff
The tigervnc dependency isn't fixed in the diff above, sorry.
@pdynarowski Cleanly rebuild the xrdp package instead, it builds fine with OpenSSL 3.
it doesn't work after update my manjaro (2022-11-2022)
journalctl -xe
lis 24 10:26:38 manjaro systemd[1]: xrdp.service: Job xrdp.service/start failed with result 'dependency'.
xrdp-sesman -ns
xrdp-sesman: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
xrdp -ns
xrdp: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
pacman -Syu openssl-1.1
As others have asked, please remove the tigervnc dependency. fow0ryl's suggested optdepends should be perfect. Dependency on tigervnc is unnecessary and if you have tightvnc or realvnc installed it creates a dependency conflict and you are forced to uninstall them in order to install xrdp which shouldn't be the case.
Optional dependencies should typically be marked as optional.
Pinned Comments
Abzie commented on 2024-05-10 14:40 (UTC)
If upgrading from 0.9.x, please read the 'User Changes' section from the release page:https://github.com/neutrinolabs/xrdp/releases/tag/v0.10.0
There is one breaking change that require manual intervention but there are three other changes that will continue to work for now.
xRDP states: Users are urged to heed any generated configuration warnings and update their configurations. Later major versions of xrdp may remove these warnings, or introduce other behaviours for the affected parameters.