Good source for support for connection issues XRDP > Windows Remote Desktop?

[thephatmaster]

Hi all, I've been happily using Ubuntu 20.04 via WSL2 where it's faster for some work tasks. I login to an XFCE desktop - to use emacs and a browser, using XRDP and Windows Remote Desktop.

I'm getting the dreaded login failed for display 0 issue (fuller details below), and have tried various support methods and have had no response from anyone able to help me debug.

Full issue (if it assists)

What I've done so far:

1. I've tried reinstall of XRDP via the online installation script;
2. I've created a new user with "proper" credentials (a password with numbers, capitals, symbols) , but can't connect to a session for that user either
3. Tried changing my user's password to use symbols capitals numbers etc.
4. Tried to seek help on: the Ubuntu forum; r/linuxquestions; r/techsupport; and r/WSL2

*The issue: *

I get the message:

Connecting to sesman IP 127.0.0.1 port 3350 sesman connect ok sending login info to session manager, please wait...
login failed for display 0

I'm not sure where to even begin debugging this. There are all sorts of avenues, seemingly not related to my exact setup, suggested online (other OSs', session managers etc)

wsl --status returns

Default Distribution: Ubuntu
Default Version: 2
Windows Subsystem for Linux was last updated on 04/04/2022
WSL automatic updates are on.
Kernel version: 5.10.102.1

lsb_release -a returns

No LSB modules are availale.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal

[matt335672]

Hi @thephatmaster

I'll explain a bit of the architecture, and that may make it a bit clearer on how to debug this.

The first thing I should say is that the inter-process communication between the xrdp processes needs improving.We're working on this (see #1961), and although a lot of the plumbing is in place, we haven't implemented some of the higher-level functions. I appreciate the quite detailed information you've provided, but to my mind we should be making problems like this easier to troubleshoot anyway.

There are two main executables involved in starting a session:-

Executable	Log File	Purpose
xrdp	/var/log/xrdp.log	Speaks the RDP protocol. Interfaces to an X server (Xorg or Xvnc) which is run as part of the session startup
xrdp-sesman	/var/log/xrdp-sesman.log	Responsible for authenticating the user, and starting the session

I'm simplifying slightly, but currently, when xrdp asks xrdp-sesman to authenticate a user and start a session, it receives a single value back. This value is the display number of the started X server, with 0 being used to report failure. login failed for display 0 therefore means some kind of authentication failure, or a failure of the early stages of session initialisation.

Here is a non-exhaustive list of possible reasons:-

• The password for the user is incorrect
• The PAM stack has failed to authenticate (or authorize) the user for some reason.
• xrdp-sesman is unable to find a spare display number.

The first place to start is to look in the log file for xrdp-sesman where more information will be available. Could you have a look and report back?

[matt335672]

It's an interesting failure, certainly.

When a session ends, the X server number gets returned to the free pool. We don't see this error very often.

One likely cause is that a lot of processes are using X11 display sockets for other purposes. Have a look in the following places.

1. What does ps -ef | grep X show?
2. What do you get for ls -l /tmp/.X11-unix/ ?
3. For sudo ss -ltn are you getting a lot of TCP sockets in the 6000 range and up?

Using ssh -X to reach a machine will use up a display number. If these sessions aren't ended correctly, it's possible to run out of display numbers.

BTW, the standards only allocate 64 TCP port numbers for X11 servers (6000-6063). So once you get above display 63, expect 'interesting' things to happen.

[thephatmaster]

Perhaps this is a WSL(2) specific issue.

I'm not connecting by SSH, as I'm essentially just connecting the machine to itself via Localhost to load a Graphical DE on WSL2

1:

<USER>      107   105  0 11:52 ?        00:00:01 /usr/lib/xorg/Xorg :61 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log                                                                                
<USER>      223   206  0 11:52 ?        00:00:00 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libnotification-plugin.so 10 16777227 notification-plugin Notification Plugin Notification plugin for the Xfce panel                                                                                                    
<USER>      430   415  0 12:27 pts/1    00:00:00 grep --color=auto X 

2: looks like I might be getting close to display 63?

srwxrwxrwx 1 <USER> <USER> 0 Aug  1 10:39 X57                                                                             
srwxrwxrwx 1 <USER> <USER> 0 Aug 22 09:08 X58                                                                            
 srwxrwxrwx 1 <USER> <USER> 0 Aug 22 09:17 X59                                                                             
srwxrwxrwx 1 <USER> <USER> 0 Aug 22 09:47 X60                                                                            
srwxrwxrwx 1 <USER> <USER> 0 Sep 20 11:52 X61

3: I'm not sure what the output should look like, but it's:

State        Recv-Q        Send-Q               Local Address:Port                Peer Address:Port       Process 
LISTEN       0             4096                     127.0.0.1:8384                     0.0.0.0:*                        
LISTEN       0             4096                             *:22000                          *:*                       
LISTEN       0             2                            [::1]:3350                        [::]:*                        
LISTEN       0             2                                *:3390                           *:* 

[matt335672]

That's interesting - thanks.

The files in 2. above are sockets left over from previous X server runs. X servers are normally very good at tidying up after themselves, even when they are killed, and so it looks to me the xrdp session termination is resulting in the X server being terminated with something like a kill -9.

It may be something to do with the way you're terminating the session, or it may be WSL specific. How are you actually terminating the session?

[thephatmaster]

Apologies for the delay - I'm terminating the session usually by shutting down the machine (with a few hibernates between shutdowns). Sometimes I will close Remote Desktop, but I rarely go out of my way to shutdown the wsl session

[matt335672]

Thanks.

There's a service that runs at startup (on a standalone Ubuntu system) called systemd-tmpfiles-setup.service. If this isn't running, or doesn't have the usual configuration, funny things may happen.

What do you get for sudo systemctl status systemd-tmpfiles-setup.service, and ls -l /usr/lib/tmpfiles.d/x11.conf ?