-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xrdp-sesman fails, rendering xrdp logins impossible on WSLg / Ubuntu 22.04 #2752
Comments
There seem to be multiple problems here. Let's start with xrdp. At some point you've changed the port it's listening on from 3389 to 3390. That's fine, but it looks like something else is on that port already:-
I'll assume that you want to use port 3390 on your VM. Can you restart the system and then post the results of these two commands:-
|
Yes, i wanted to use port 3390 since this is on WSL and how i understand it is that port 3389 is how X11/Wayland renders graphical programs outside of RDP... this is basically a second RDP connection. the results for sudo journalctl -xeu xrdp.service: user@XOTICPC:/var/log/apache2$ sudo journalctl -xeu xrdp.service the results of sudo ss -lp sport = :3390: user@XOTICPC:/var/log/apache2$ sudo ss -lp sport = :3390 |
That all looks OK. What do you now get for |
right now it's working normally...
and when i run the next command, i get this:
|
It looks like everything is working normally at the moment. When it fails, can you repost the output of both |
Disk space isn't that much of an issue. I've restarted Windows Subsystem for Linux and this is what i get as a result:
The "2 zombie processes" makes me wonder if this is related?
xrdp seems to fail becuase it depends on xrdp-sesman... which dies for... reasons.
it's at this point that i'd need to uninstall xrdp, restart WSL then re-install if i want to login via RDP... This is all very bewildering for me... I have no idea what causes it, or how to remedy it... I've noticed this problem also happens with apache2 (except it seems to freeze on starting or restarting)... i suspect that is also related, but it getting beyond the scope of this bug report... |
xrdp-sesman is getting a SIGINT or a SIGTERM from somewhere. This is generating the message Maybe we can hack the unit files about to fix this. What do you get for these commands:-
|
that returns the following:
i did try creating /run/xrdp/ as root and chmod it to +777 but that doesn't seem to make a difference (and it disappears between restarts of WSL, anyway)... |
Those files look pretty standard to me. Since the only place that xrdp-sesman can be getting a SIGTERM from is systemd (at least as far as I can tell), I suggest we try simplifying these files to the bare minimum that will work. The changes below will remove most of the coupling between the services. This should be OK I think for your use-case. Can you make the following edits:- /lib/systemd/system/xrdp.service`
/lib/systemd/system/xrdp-sesman.service`
Then, This should give to the following:-
Let me know how it goes. |
alrighty! i made those edits and restarted WSL again...
so far it looks like business as usual. let's attempt logging in, though... hrmm. still a blank screen... okay, let's see what's going on.
Edit:
This is quite the head-scratcher... i'll be honest, I don't get it... Edit: I ran systemctl status xrdp.service and systemctl status xrdp-sesman.service afterwards and this is what came up:
after restarting dbus via sudo systemctl restart dbus, i tried both "systemctl start xrdp" and "systemctl start xrdp-sesman" but the command just hangs, as if waiting for something else to happen first and i have to type [CTRL]+[C] to abort.. the same happens when i attempt "systemctl enable xrdp"... it just hangs after saying this:
|
There's a bit of a clue here:-
It looks like xrdp is already running, but when you log in, for some reason the system tries to start another instance of xrdp in addition to the one that is already active. This one fails as port 3390 is already in use. You've also got this output:-
I've just noticed that Debian ship the xrdp package with a SysV init script as well as a systemd unit file. I don't know why they do this, but maybe it's to support running without systemd. This may be confusing things on WSL. Can you take a copy of this script and remove it?
Then try restarting WSL and see what happens. |
is the second line supposd to be two seperate lines? i get this: user@XOTICPC:~$ cd /etc/init.d/xrdp ./xrdp.init.sav did you mean something like: i did that and restarted WSL and still get the error that xrdp-sesman can't start, and that xrdp depends on it, so it can't start... i'm honestly wondering if i should just clone the git repository and compile from source... |
That's what I meant - sorry. Or near enough anyway. The problem you've got is the way systemd is working. I can't see it will be any better with compiling from source. I don't understand why xrdp.service is dependent on xrdp-sesman.service. I thought we'd removed that link by editing the service manifest for xrdp-sesman and removing the |
yeah, i did remove it.. apparently, the system re-added it a couple of times. i ran systemctl daemon-reload three times and it finally accepted the edits.
so, let's see what's going on with the daemon processes themselves...
THAT"S A HUGE CHANGE! Usually, xrdp-sesman dies, and that makes xrdp not load... okay, let's see if xrdp loads next!
Well, as Bon Jovi sang in the 1980s: We're Half-way There! Edit:
so far, nothing is listening on port 3390, but xrdp seems to think so.... one reboot of WSL later and xrdp-sesman is back to failing as well... and on boot, i saw this one line:
I bet the two are related (like, a handle or PID not being given up properly when the system shuts down... what's bizarre is if i edit /etc/xrdp/xrdp.ini and tell it to use port 3391, the service then starts and i can log in, even without xrdp-sesman running... i just don't want to have to constantly change ports... |
Your I've had a look at a few online articles. It's possible one of your zombie processes used to be an xrdp process and it's holding on to the port. This would be down to some problem related to the interaction between systemd and the kernel. I don't know enough about WSL to know what 'shutting down WSL' does. After you restart WSL, what does the |
user@XOTICPC:/etc/apache2$ uptime yeah, that looks right. i last ran wsl --shutdown in PowerShell around this time yesterday. hrmm, i guess this is just a bug with WSL... though i wonder if there's an option like "ask3390" for xrdp to request port 3390, before settling on something else automatically, like what kali linux did for win-kex and their build of xrdp... |
The other problem you've got is that sesman listens on a port too, so you're going to have exactly the same problems with that. From what I've read about WSL, the kernel is separate from the distro that's running on it. That might be something to do with it, but it's not anything I have any experience with. The other possibility is you've got more than one VM running on the WSL kernel, and they're both tripping over each other. |
The only thing I have in WSL is ubuntu... nothing else is running there... i think this might just be a kernel issue within WSL that's causing xrdp to choke. This didn't happen until WSL gained native systemd support a few months back... |
You can check who listens on a port. For example:
and then
|
xrdp version
0.9.17-2
Detailed xrdp version, build options
Operating system & version
WSLg / Ubuntu 22.04.2 LTS
Installation method
dnf / apt / zypper / pkg / etc
Which backend do you use?
xorgxrdp
What desktop environment do you use?
xfce
Environment xrdp running on
WSLg on Windows 10 Professional 64-bit
What's your client?
Microsoft's official client
Area(s) with issue?
Session manager (sesman)
Steps to reproduce
Attempt to log in via Microsoft's remote desktop program. Affter logging in, the system just shows an empty green or black screen. If you check systemctl status xrdp, the system says "failed" due to a dependency (xrdp-sesman) failing. xrdp-sesman.
✔️ Expected Behavior
I expected to be able to log in to the xfce desktop in my Windows Subsystem for Linux Ubuntu install
❌ Actual Behavior
No login is performed, the client just stops responding and I have to close it. Restarting WSL does nothing. Restarting xrdp does nothing. re-installing xrdp and xfce4 is hit-or-miss... Genie is not installed, as WSL2 and WSLg now support Systemd natively.
Anything else?
I saw this article ( https://medium.com/@riley.kao/wsl2-ubuntu20-04-gui-remote-desktop-connection-rdp-2bbd21d2fa71 )on how to connect to WSL2 and WSLg via the Remote Desktop Protocol, and decided to give it a shot, and for a while, it worked... but if i log out and wait a while (perhaps an hour or so), or restart WSL, i lose the ability to log back in, and it's very difficult to regain it...
the systemd service "xrdp" fails becuase it depends on "xrdp-sesman" but that fails becuase of the following errors:
results of "systemctl status xrdp.service" :
results of "journalctl -xeu xrdp.service" :
at boot, this is what appears when i type "sudo systemctl start xrdp-sesman":
That directory, /var/run/xrdp/ does not exist.... and if i try to create it, the thing just gets deleted during the next boot, and fails anyway.
Why is it failing to end that process? it's running as root!
contents of /etc/xrdp/startwm.sh:
(commenting-out unset and .$HOME/.profile does nothing, by the way)
contents of beginning of /etc/xrdp/xrdp.ini:
I've attached log files in the hopes we can figure out why this happens. Xrdp.txt is the /etc/xrdp/xrdp.ini file.
xrdp.log
xrdp-sesman.log
xrdp.txt
The text was updated successfully, but these errors were encountered: