XRDP session immediately closes after loggin in.

[faya9551]

Hi

I have xrdp installed on both RH 7.6 and 7.7 both are showing the same behavior. Can you please suggest if I have to make any config changes for this to work? I do not have file on Redhat : /etc/xrdp/startwm.sh

tigervnc.x86_64                                      1.8.0-17.el7                 @rhel_7Server_x64_localrepo
xrdp.x86_64                                          1:0.9.11-1.el7                @EPEL7_x64_localrepo

Logs :  xrdp-sesman.log

[20190917-14:00:38] [INFO ] shutting down sesman 1
[20190917-14:00:38] [DEBUG] Closed socket 7 (AF_INET 127.0.0.1:3350)
[20190917-14:00:38] [DEBUG] libscp initialized
[20190917-14:00:38] [INFO ] starting xrdp-sesman with pid 2577
[20190917-14:00:38] [INFO ] listening to port 3350 on 127.0.0.1
[20190917-14:00:52] [INFO ] A connection received from 127.0.0.1 port 50236
[20190917-14:00:52] [INFO ] ++ created session (access granted): username user, ip **.***.**.***:53246 - socket: 12
[20190917-14:00:52] [INFO ] starting Xvnc session...
[20190917-14:00:52] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:5910)
[20190917-14:00:52] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:0)
[20190917-14:00:52] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:5911)
[20190917-14:00:52] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6011)
[20190917-14:00:52] [DEBUG] Closed socket 9 (AF_INET 0.0.0.0:6211)
[20190917-14:00:52] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20190917-14:00:52] [INFO ] calling auth_start_session from pid 2715
[20190917-14:00:52] [DEBUG] Closed socket 7 (AF_INET 127.0.0.1:3350)
[20190917-14:00:52] [DEBUG] Closed socket 8 (AF_INET 127.0.0.1:3350)
[20190917-14:00:52] [INFO ] Xvnc :11 -auth .Xauthority -geometry 3840x2174 -depth 24 -rfbauth /home/user/.vnc/sesman_passwd-user@rpub1234.user.company.com:11 -bs -nolisten tcp -localhost -dpi 96
[20190917-14:00:52] [CORE ] waiting for window manager (pid 2717) to exit
[20190917-14:00:53] [CORE ] window manager (pid 2717) did exit, cleaning up session
[20190917-14:00:53] [INFO ] calling auth_stop_session and auth_end from pid 2715
[20190917-14:00:53] [DEBUG] cleanup_sockets:
[20190917-14:00:53] [INFO ] ++ terminated session:  username user, display :11.0, session_pid 2715, ip **.***.**.***:53246 - socket: 1

[cybertramp]

Sorry this is not a solution!

The same problem is happening with Xubuntu 18.04 LTS, Xubuntu 19.04. When I try to connect through mstsc on Windows 10, I get a black screen after login and exit.

I searched for half a day and tried many solutions but showed the same problem..

Below is the log when connecting.

var/log/xrdp.log

[20190918-21:04:43] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20190918-21:04:44] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20190918-21:04:44] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20190918-21:04:44] [DEBUG] return value from xrdp_mm_connect 0
[20190918-21:04:44] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20190918-21:04:44] [DEBUG] xrdp_wm_log_msg: started connecting
[20190918-21:04:44] [INFO ] lib_mod_log_peer: xrdp_pid=11003 connected to X11rdp_pid=11017 X11rdp_uid=1000 X11rdp_gid=1000 client_ip=::ffff:192.168.0.28 client_port=1661
[20190918-21:04:44] [DEBUG] xrdp_wm_log_msg: connected ok
[20190918-21:04:44] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20190918-21:04:44] [DEBUG] Closed socket 16 (AF_INET6 ::1 port 51898)
[20190918-21:04:45] [DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.0.50 port 3389)
[20190918-21:04:45] [DEBUG] xrdp_mm_module_cleanup
[20190918-21:04:45] [DEBUG] Closed socket 17 (AF_UNIX)
[20190918-21:04:45] [DEBUG] Closed socket 18 (AF_UNIX)

/var/log/xrdp-sesman.log

[20190918-21:04:43] [INFO ] A connection received from ::1 port 51898
[20190918-21:04:44] [INFO ] ++ created session (access granted): username laladot, ip ::ffff:192.168.0.28:1661 - socket: 12
[20190918-21:04:44] [INFO ] starting Xorg session...
[20190918-21:04:44] [DEBUG] Closed socket 9 (AF_INET6 :: port 5910)
[20190918-21:04:44] [DEBUG] Closed socket 9 (AF_INET6 :: port 6010)
[20190918-21:04:44] [DEBUG] Closed socket 9 (AF_INET6 :: port 6210)
[20190918-21:04:44] [DEBUG] Closed socket 8 (AF_INET6 ::1 port 3350)
[20190918-21:04:44] [INFO ] calling auth_start_session from pid 11007
[20190918-21:04:44] [DEBUG] Closed socket 7 (AF_INET6 ::1 port 3350)
[20190918-21:04:44] [DEBUG] Closed socket 8 (AF_INET6 ::1 port 3350)
[20190918-21:04:44] [INFO ] /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log  
[20190918-21:04:44] [CORE ] waiting for window manager (pid 11013) to exit
[20190918-21:04:45] [CORE ] window manager (pid 11013) did exit, cleaning up session
[20190918-21:04:45] [INFO ] calling auth_stop_session and auth_end from pid 11007
[20190918-21:04:45] [DEBUG] cleanup_sockets:
[20190918-21:04:45] [DEBUG] cleanup_sockets: deleting /var/run/xrdp/sockdir/xrdp_chansrv_audio_out_socket_10
[20190918-21:04:45] [DEBUG] cleanup_sockets: deleting /var/run/xrdp/sockdir/xrdp_chansrv_audio_in_socket_10
[20190918-21:04:45] [DEBUG] cleanup_sockets: deleting /var/run/xrdp/sockdir/xrdpapi_10
[20190918-21:04:45] [INFO ] ++ terminated session:  username laladot, display :10.0, session_pid 11007, ip ::ffff:192.168.0.28:1661 - socket: 12

~/.xsession

xfce4-session

/etc/xrdp/startwm.sh

## SKIP ##
fi

if test -r /etc/profile; then
        . /etc/profile
fi
#### I tried several times but it doesn't work!
#test -x /etc/X11/Xsession && exec /etc/X11/Xsession
#exec /bin/sh /etc/X11/Xsession
xfce4-session
#startxfce4

I think it's an xorg problem, but I haven't found a solution yet. Do you know how to solve this problem? or bug?

[Abinayasandhiya]

Hi @faya9551

Following may be the reason for your issue:

1. Please check whether all the desktop manager component been installed if not please use yum groupinstall "KDE" and GNOME
2. Check you home directory whether you have any .Xclients file. if yes change the file permission to chmod +x .Xclients and add the startkde/gnome-session inside this file. NOTE: Empty file will be create the session close

[zicklag]

I am getting the same thing, but it only seems to happen if I log into the machine locally and then, without logging out, try to log in with xrdp. If I am not logged in on the machine and I try to log in with xrdp then it works. Also if I disconnect from an xrdp session and a reconnect to the logged in session it still works. That's happening on a Pop! OS 19.04 VM.

[metalefty]

No feedback from the reporter, closed.

[romybompart]

Hi people! My XRDP stopped working few weeks ago. Then I started working with the xfce4. But It does not allow me to see some applications for example kivy applications. So I started to dig out how to solve this issue. But I can't see how. Using xrdp i got the following status:

rb@rb-desktop:/home$ systemctl status xrdp.service
● xrdp.service - xrdp daemon
   Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-06-19 18:29:52 CDT; 4min 58s ago
     Docs: man:xrdp(8)
           man:xrdp.ini(5)
  Process: 10316 ExecStop=/usr/sbin/xrdp $XRDP_OPTIONS --kill (code=exited, status=0/SUCCESS)
  Process: 10391 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
  Process: 10356 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
 Main PID: 10393 (xrdp)
    Tasks: 2 (limit: 4183)
   CGroup: /system.slice/xrdp.service
           ├─10393 /usr/sbin/xrdp
           └─10688 /usr/sbin/xrdp

jun 19 18:34:16 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:19 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:23 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:26 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:30 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:33 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:37 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:40 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:44 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)
jun 19 18:34:47 rb-desktop xrdp[10688]: (10688)(548297039888)[DEBUG] Closed socket 21 (AF_UNIX)

When I am trying to run Kivy applications in xfce4 this is what I got:

MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)
libGL error: failed to load driver: swrast
X Error of failed request:  GLXBadContext
  Major opcode of failed request:  154 (GLX)
  Minor opcode of failed request:  6 (X_GLXIsDirect)
  Serial number of failed request:  36
  Current serial number in output stream:  35

This is my system info: rb@rb-desktop:/usr/lib/nvidia/license$ uname -a Linux rb-desktop 4.9.140-tegra #1 SMP PREEMPT Tue Jul 16 17:04:49 PDT 2019 aarch64 aarch64 aarch64 GNU/Linux

Best Regards

[nathaneltitane]

Currently experiencing the same issue when attempting to xrdp into a Termux chroot running in Android 10 - Samsung Galaxy Note 10+

Ubuntu version is 20.04

VNC setup functions when using vnc server and vnc client:

vnserver > vnc client : ok vncserver > rdp : not ok xrdp > rdp client : not ok

[mailinglists35]

this worked for me on oracle linux 8 minimal install with xfce4 from epel:

echo xfce4-session > $HOME/.xsession
chmod +x .xsession

there are lots of failsafes but when the system is minimally installed there is really no failsafe on ol8 so failing to launch a desktop environment will result in normal action = ending the xorg xrdp session

places to look to see how things are tried: /usr/libexec/xrdp/startwm.sh <- this is where searching for a desktop session or window manager begins

inside you will see it is searching for /etc/X11/xinit/Xsession /etc/X11/Xsession /etc/X11/xdm/Xsession etc... look inside those which eventually you'll see failsafes desperately trying $HOME/.xsession, $HOME/.Xclients, /etc/X11/xinit/Xclients, xsm, xclock, xterm, twm, firefox... but NONE of these come into a minimal ol8 installation! that's why you HAVE to intercept these and put something into your $HOME/.xsession or $HOME/.Xclients and make it executable (scripts check if they are executable)

if you want it system-wide, put this in /etc/sysconfig/desktop (/etc/X11/xinit/Xclients looks for it): PREFERRED=/bin/icewm-session (or /usr/bin/xfce4-session or whatever unusual wm session you have - make sure the binary is there, for example xfce is installed by xfce4-session rpm)

---

EDIT (note for myself) In Ubuntu 20.04LTS the startwm script is shipped in /etc/xrdp and looks only for /etc/profile and /etc/X11/Xsession. In turn Xsession loads snippets from Xsession.d and references also $HOME/.Xsession in addition to $HOME/.xsession

Also there is no configuration file like on RHEL about system default session but 50.x11-common_determine-startup Xsession.d file is looking in order for x-session-manager, x-window-manager and x-terminal-emulator in /usr/bin/, which all are handled by update-alternatives system. So in Ubuntu you would need to have update-alternatives configure the /usr/bin/x-session-manager symbolink link to launch the desired desktop environment session manager. Normally that happens automatically when you install some popular desktop environment but in case you don't see any listed you have to add it manually with update-alternatives --install [...]

[jerryamiller]

this worked for me on oracle linux 8 minimal install with xfce4 from epel:

echo xfce4-session > $HOME/.xsession
chmod +x .xsession

there are lots of failsafes but when the system is minimally installed there is really no failsafe on ol8 so failing to launch a desktop environment will result in normal action = ending the xorg xrdp session

places to look to see how things are tried: /usr/libexec/xrdp/startwm.sh <- this is where searching for a desktop session or window manager begins

inside you will see it is searching for /etc/X11/xinit/Xsession /etc/X11/Xsession /etc/X11/xdm/Xsession etc... look inside those which eventually you'll see failsafes desperately trying $HOME/.xsession, $HOME/.Xclients, /etc/X11/xinit/Xclients, xsm, xclock, xterm, twm, firefox... but NONE of these come into a minimal ol8 installation! that's why you HAVE to intercept these and put something into your $HOME/.xsession or $HOME/.Xclients and make it executable (scripts check if they are executable)

if you want it system-wide, put this in /etc/sysconfig/desktop (/etc/X11/xinit/Xclients looks for it): PREFERRED=/bin/icewm-session (or /usr/bin/xfce4-session or whatever unusual wm session you have - make sure the binary is there, for example xfce is installed by xfce4-session rpm)

This worked for me in Ubuntu Bionic. Thanks very much for posting it.

[tyasird]

chmod +x .xsession

worked for Ubuntu, thanks a lot.

[d3al]

I'm having a similar issue.

Ubuntu 20.04

I have 10 of these machines deployed across multiple client sites with different network/firewall configurations. These machines are deployed with a standard configuration which includes xrdp, desktop environment budgie desktop with lightdm, how we connect to the clients and these machines are under configuration management ensuring the configs are reverted back.

One client has two machines that was recently deployed and I'm getting this issue on only these two machines.

At this point, I'm only getting this problem when I connect to the console of the machine (shared with the physical user). Once I get disconnected which might be right after authentication or up to 15 seconds. I can see and interact with the desktop depending how long the session lasts. If I reconnect, I might get disconnected again or the connection might be stable. usually after 2-3 reconnects I will get a stable connection.

If I connect to a virtual session, using a different user the session hasn't disconnected so far. I'm not able to login to a virtual desktop using the console user as it's always in use.

I captured packets with wireshark from the connecting source and there is no reset packets or anything that indicates a network problem.

There is no .xsession in the user home directory on any of the deployed machines. All machines are updated at the same time.

[matt335672]

@d2ai - this sounds like a completely different problem. You mention the console, so I imagine you're using x11vnc or similar, and connecting to that.

Tagging a description on to a closed issue is never a good idea. May I trouble you to open a separate issue for this? Please include details of how you're connecting to the console on the machines, and whether you're using xrdp from the repositories or another source.

[d3al]

Yes it's connecting to x11vnc. This issue may not be xrdp related at all but for completeness.

I'm using apache guacamole to connect to these systems over RDP which connects to x11vnc and there are two clipboard options for each connection. When I have them enabled, I get the disconnection issue and since having these options unchecked (default), I haven't had the issue at least not yet. Comparing between the broken machine and a working machine, the difference in the logs is the broken machine is disabling clipboard redirect.

Disable copying from remote desktop Disable pasting from client

[matt335672]

It's almost certainly #1885 which was fixed in v0.9.17. You don't see it on a full xrdp session as in this configuration the clipboard is handled by xrdp-chansrv.

If you're not in a position to upgrade, I can't offer you any workarounds other than the ones you've found. x11vnc does not contain an option to limit the clipboard size that I can find. You can try -noclipboard so that large text selections on the X11 side are not looked for, but I can't see any advantage over disabling the clipboard at the client.

[sanba06c]

@jerryamiller,

echo xfce4-session > $HOME/.xsession
chmod +x .xsession

It worked for Kali Linux. Thank you so much.

[jesheppard]

For Rocky Linux 8 and Fedora 39, I got it working by using these steps:

1. sudo dnf groupinstall Xfce -y
2. sudo dnf install xrdp -y
3. sudo systemctl enable xrdp --now
4. echo xfce4-session > $HOME/.xsession
5. sudo firewall-cmd --permanent --add-service=ms-wbt; sudo firewall-cmd --reload
6. sudo systemctl restart xrdp

My system was initially installed with the Environment Group: Server I didn't have to change that and kept it at run level 3.

systemctl get-default
multi-user.target

If you want to add more security by user access, see this page:: https://c-nergy.be/blog/?p=18536

I did not need to install tigervnc as some procedures suggested.

[pcwii]

@jerryamiller This worked for me on Debian GNU/Linux 10 (buster)

echo xfce4-session > $HOME/.xsession
chmod +x .xsession
sudo systemctl restart xrdp

[alexbodn]

i had the same problem, and found some amazing thing: something changed my /etc/xrdp/startwm.sh: the version that apparently worked became /etc/xrdp/startwm.sh0. the apparently bad version was /etc/xrdp/startwm.sh and /etc/xrdp/startwm.sh1. reading this discussion lead me to open the file and actually fixing the problem. thank you very much for the publishing of the whole untouched discussion.

[beso9595]

Debian GNU/Linux 11 (bullseye) / Gnome This worked for me: http://c-nergy.be/blog/?p=17113

[alexbodn]

thank you beso, this seems to be the best way to go!

alex

On Fri, Jan 27, 2023, 21:12 Beso Bantsadze @.***> wrote:

Debian GNU/Linux 11 (bullseye) / Gnome This worked for me: http://c-nergy.be/blog/?p=17113

— Reply to this email directly, view it on GitHub https://github.com/neutrinolabs/xrdp/issues/1412#issuecomment-1406962480, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABER7ALK5H4QDSYOT2IIYQDWUQM3HANCNFSM4IXVDHWA . You are receiving this because you commented.Message ID: @.***>

[moonlightz]

Nothing really works for me. Every solution ends in frustration. Install, uninstall, add a modification, remove it, restart service.... hour after a hour. Xrdp works fine on my RPI3A+ but only 512mb of RAM, can't do much. I am testing a tv box with armbian bullseye firstly installed, upgraded, upgraded to bookworm... still nothing. On my Windows machine, I launch the client, I type the address or the name of the target host, it opens the login dialog, I type the username and password, one second later, the session is closed. I didn't yet allow root to be allowed as possible user. I'm wasting hours now on this. When I was setting up xrdp on RPI3, I obviously solved the issues I encountered and ended up working, but not now. I still have some things to try and if nothing works... vnc will be...

EDIT: I fixed it finally... Using SSH, I created another user using "adduser test", connected using Windows client, entered "test" as username and the password, and it worked. It loaded the MATE desktop, then logged out and entered the original username and no joy, the session gets killed. Then I troubleshooted the home directories, I removed the junk made on my home directory to match what I see on the /home/test directory including removing key.pem and logs from xorgxrdp while keeping connecting to the remote session. One file left on my original account: ".Xauthority". Then I simply deleted the file and connected again and that worked. It loaded the freaking desktop environment after over a day of "trial and error" methods. But still something was screwing local language settings because MATE was loading the English strings when I have the shell set to other language. That problem was tackled by reconfiguring locales on all accounts. I am not sure if the login session problem will come back... Yet to login locally to the desktop environment.

[mailinglists35]

this worked for me on oracle linux 8 minimal install with xfce4 from epel:

echo xfce4-session > $HOME/.xsession
chmod +x .xsession

updating this for my own use: in case of icewm and oracle linux 9 minimal install:

echo icewm-session > $HOME/.xsession

[dca00]

xrdp has not worked properly since about 2012-2013. There was some forsaken release around that time, and it screwed everything up. Since then, nothing but impossible-to-solve problems. Prior to that there were no problems whatsoever: install and forget.

I tried everything that I found online: fixes to like 1/2 of the OS files, all in order to have xrdp. I suggest that 1) the developer does not care and 2) they are happy watching us bang our heads on our desktops.

Why does xrdp-sesman wait for window manager to exit and then exits instead of serving the user's request? This was not a problem prior to 2012.

The code base should be just rolled back to the previous state when it did work because there is absolutely zero, nada, zilch worth of value in any changes committed ever since: they do not work.

If developers are reading this, then simply roll everything back to pre-2012 and see what was that accursed change that broke everything in this forsaken project.

And, for crying out loud, test before you push a release to distros. Having such humongous problems for decades is pathetic.

[metalefty]

And, for crying out loud, test before you push a release to distros. Having such humongous problems for decades is pathetic.

To be clear, we never PUSH a release to distros. Distros FETCH releases on their own decisions.

[dca00]

we never PUSH a release to distros. Distros FETCH

I am content to notice that you picked on semantics only. It means that the rest of my observations is actual, accurate, to the point and spot-on. By the way, it was push as in git push. So it is also accurate. Touché.

[matt335672]

@dca00 - comments like yours above may make you feel a bit better, but they do absolutely nothing to solve your problems or those of others.

Frankly I don't understand your comment above. Could you raise a more focussed issue, and we can take a look at it? That way everyone benefits.

[metalefty]

@dca00 IIRC, I saw you on GitHub for the first time today. Why didn't you raise any issue for if xrdp has not been working properly for a decade? How can we know xrdp is not working for you unless you let us know? Never. Definitely never!

I hope you could report an issue with details as a member of the community. Everyone can report the issue on GitHub but you never reported your impossible-to-solve problems.

[dca00]

This is not about me. This is about xrdp and its developers. You must have lived in an ivory tower, for all these years, if you are still oblivious to the fact that since about 2012-2013 xrdp does not work. It is as plain as simple as I put it: xrdp does not work. Completely. Totally. The definition of 'works' is as follows: After d/l a distro's ISO image, burning it on the media, booting with it and following prompts to arrive at a default installation of any particular distro and finally running whatever apt/dnf/zypper/yum xrdp install we run mstsc.exe from Windowze and voila, we are logged into our Linux box. The definition of 'does not work' is as follows: Having installed Linux and xrdp we cannot connect. This is the present state of xrdp. Google 'xrdp' and you will see hundreds if not thousands of questions that all revolve around the same topic: why does xrdp rain errors on me but does not work, no matter what? You will find them everywhere: on linuxquestions.org, askubuntu.org, stackexchange.com, github, yada, yada, yada.

I gave up 12 years ago, after a one-year-long back and forth with one of your devs. To my every attempt to troubleshoot xrdp he kept repeating that he only tests his code against Gnome, and that is not something I have or can put on my systems. Still, 12 years and like 12 different versions of various Linuxae later, nothing works, with the same symptoms.

[nathaneltitane]

This is not about me. This is about xrdp and its developers. You must have lived in an ivory tower, for all these years, if you are still oblivious to the fact that since about 2012-2013 xrdp does not work. It is as plain as simple as I put it: xrdp does not work. Completely. Totally. The definition of 'works' is as follows: After d/l a distro's ISO image, burning it on the media, booting with it and following prompts to arrive at a default installation of any particular distro and finally running whatever apt/dnf/zypper/yum xrdp install we run mstsc.exe from Windowze and voila, we are logged into our Linux box. The definition of 'does not work' is as follows: Having installed Linux and xrdp we cannot connect. This is the present state of xrdp. Google 'xrdp' and you will see hundreds if not thousands of questions that all revolve around the same topic: why does xrdp rain errors on me but does not work, no matter what? You will find them everywhere: on linuxquestions.org, askubuntu.org, stackexchange.com, github, yada, yada, yada.

I gave up 12 years ago, after a one-year-long back and forth with one of your devs. To my every attempt to troubleshoot xrdp he kept repeating that he only tests his code against Gnome, and that is not something I have or can put on my systems. Still, 12 years and like 12 different versions of various Linuxae later, nothing works, with the same symptoms.

+1 to this

I was planning on integrating it to my dextop project and simply gave up due to zero help or resources to enable a bugfix/solution to it actually just not working regardless of attempts and methods.

[dca00]

To put things in a perspective for you, devs, here's one of MANY threads that shows that almost everything about xrdp is a royal screw-up: https://askubuntu.com/questions/773626/xrdp-login-failed Configuration files are messed up OOB. Scripts are messed up OOB. Permissions are messed up OOB. Files missing OOB. There are obscure, undocumented requirements for xrdp credentials that have no basis in UNIX security (login names only in lowercase, passwords only so long/short, no such characters allowed, etc). And we have to discover all those things ourselves, by way of extensive trial and error. The totality of these issues sums up in one sentence: xrdp does not work. It is not a working component of Linux. It is an excruciating torture to set it up and manage.

If you are going to claim that all of that is a screw-up on distro maintainers' side, then another thing is wrong with xrdp: it is too difficult to correctly integrate into distros. For some reason everything else in Linuxae seems to work pretty well, at least there are no complete show-stoppers in anything else that I am aware of. Strangely, distro maintainers are able to keep up with everything else but xrdp.

Bottom line is, roll your code back to the point when it worked. No changes that you have made since bring any value for Linux community because you broke the core function of xrdp: its ability to serve remote desktop requests. We do not give a slightest damn about how more secure or sophisticated you might have made it since because you locked us out as a result.

Once it is rolled back, carefully reapply each change you have made since, one at a time, and thoroughly test before you roll out another release. Remember that there is not only Gnome out there but several more mainstream window managers: KDE, XFCE, LXDE, and MATE. It has to work equally well with all of them before it may be considered stable.

Not doing so means the highest degree of disrespect towards your users. We have suffered that for too long. It is about time someone told you directly that your product does not work though it used to.

[d3al]

I had xrdp issues a while ago and I think one of the issues was a broken xrdp version provided by the distro but I was able to put together a working set of configuration files using xrdp 9.21.1. I haven't tried a newer version but it will probably work with the configs I have. With that said, I'm running xrdp on a fleet of machines, 100+, ubuntu 20.04/22.04 all using gnome and I haven't had a single crash, so does it work? Yes, does it require dark magic and sacrifices to the Gods? Yes, probably both.

I'm worried about the move to wayland to be honest as how this is working is perfect with my xorg setup.

I think part of the issue is documentation, it's really hard to find solutions so you burn hours, days trying to find that one buried post with something that may help, but that post is just a lead, you still have to tweak it and test over and over. This documentation should be on the xrdp website, how to set it up, advanced setups, what files need to be touched, what those changes before/after so users can copy paste the config and get past the innards of linux. I agree that xrdp should work out of the box with sane defaults but is this the responsibility of xrdp for various distros? Maybe not but xrdp team should do what they can to get it to work from a fresh install on common distros. I get a sense that xrdp is just an app the distro's install, doesn't configure and never touches it again till the next release. This is why the documentation section would probably give frustrated users a path forward at trying to get past common issues.

---

From: dca00 @.> Sent: Monday, April 15, 2024 3:21 PM To: neutrinolabs/xrdp @.> Cc: d3al @.>; Comment @.> Subject: Re: [neutrinolabs/xrdp] XRDP session immediately closes after loggin in. (#1412)

To put things in a perspective for you, devs, here's one of MANY threads that shows that almost everything about xrdp is a royal screw-up: https://askubuntu.com/questions/773626/xrdp-login-failed Configuration files are messed up OOB. Scripts are messed up OOB. Permissions are messed up OOB. Files missing OOB. There are obscure, undocumented requirements for xrdp credentials that have no basis in UNIX security (login names only in lowercase, passwords only so long/short, no such characters allowed, etc). And we have to discover all those things ourselves, by way of extensive trial and error. The totality of these issues sums up in one sentence: xrdp does not work. It is not a working component of Linux. It is an excruciating torture to set it up and manage.

Bottom line is, roll your code back to the point when it worked. No changes that you have made since bring any value for Linux community because you broke the core function of xrdp: its ability to serve remote desktop requests. We do not give a slightest damn about how more secure or sophisticated you might have made it since because you locked us out as a result.

Once it is rolled back, carefully reapply each change you have made since, one at a time, and thoroughly test before you roll out another release. Remember that there is not only Gnome out there but several more mainstream window managers: KDE, XFCE, LXDE, and MATE. It has to work equally well with all of them before it may be considered stable.

Not doing so means the highest degree of disrespect towards your users. We have suffered that for too long. It is about time someone told you directly that your product does not work though it used to.

— Reply to this email directly, view it on GitHubhttps://github.com/neutrinolabs/xrdp/issues/1412#issuecomment-2057909396, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AORJFJ6TQKM3NLXWKOBMACTY5RHHXAVCNFSM4IXVDHWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVG44TAOJTHE3A. You are receiving this because you commented.Message ID: @.***>

[matt335672]

@dca00 - your post is clearly written with some feeling, but it doesn't contain anything meaningful that I can engage with on a technical level.

I can only re-iterate what I've said before. I'll say it a different way with more detail.

Open source software development projects need meaningful feedback from users. This gives the developers an idea of what features are lacking, and where (often limited) development efforts can be focussed.

This project primarily receives user communication from issues and PRs. Some of these are direct, and some are indirect (i.e. via distros).

Issues require triage by developers. For us to do this, we need technical information from users, and this needs the users to engage with us. We can't do anything with a description like "it doesn't work", or even "I have this too". We can do something with "I'm running this version of xrdp on this distro with this client and I'm experiencing these symptoms. Here are some logs". If you've opened an issue in the last 6 months you may have seen that we're now trying to gather this information when an issue is opened. The point of this is to minimise the round-trips between the developers and the users. It might seem like a faff to have to enter this, but it's important. Dissimilar issues can often present in similar ways.

It's not a perfect process by any means. All of our developers are part time. At any one time, some (or all) of us may be involved in sponsored work on xrdp and that gives us less available time for addressing user issues. We also appreciate that our users' time may be limited too and that makes it sometimes hard for them to engage with us. Some issues may be impossible for us to reproduce, particularly if they're running on non-mainstream hardware (e.g. Raspberry PI), or operating systems which can not obtain a free maintenance licence for (e.g. Solaris). Some issues can't be resolved in ways which our users are happy with. Some issues simply don't get addressed as they may be related to a part of the software that is poorly understood by the existing developers.

I see this thread currently has 19 participants. If you're reading this feel free to discuss this post further, or, if you've still got an outstanding issue with xrdp you'd like to solve try raising an issue.

I'm still hopeful we can rescue something positive from this thread. However, be warned that further rants will be ignored or deleted.

[alexbodn]

I've opened this issue due to a problem with using XRDP. The dev swiftly pointed me in the direction to search and there I found the problem. It was nothing inside Xrdp, but a script of the wrong type in a directory of my system. Xrdp is service software, deeply embedded between tectonic sized services as xorg and pam, trying to speak the rigidly defined rdp protocol. There are alternative solutions, but as of now, this one was the best solution for me, accessible from all kinds of devices and probably even from windows I don't have. Open source projects generally benefit from the users' cooperative thinking, Xrdp making no exception. I think I received more from this and other OS projects than I ever had the chance to directly contribute back. Just my point of view.