-
-
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
Unable to reconnect - reconnectwm.sh defunct #3156
Comments
That log looks fine- the errors are generated when the xrdp connection to sesman is terminated. This is interesting and may well be the cause of your problem:- login successful for display 120 VNC started connecting VNC connecting to 127.0.0.1 6020 By default VNC allocates ports for a display :$D.0 as follows:- VNC client TCP port : So for display :20.0, VNC will use TCP ports 5920 and 6020. For display 120, VNC will use ports 6020 and 6120. You can see there's a collision here. If you've got a user on :20.0, a user on :120.0 won't be able to connect, as xrdp will connect to TCP port 6020 and send it VNC commands. However port 6020 will be expecting X11 commands. Later versions of xrdp place a limit on the display number to stop this happening. A display number of 120 suggests you've got at least 111 sessions active (allocations 1 uses display 10, allocation 2 uses display 11 and so-on). This is pretty enormous, and I think needs some investigation. Do you have that many users on one machine? |
Thanks for the feedback @matt335672 We do have a lot of users. I just did a count of Xvnc sessions and currently I see 76 processes. What i suspect is happening is that some of the sessions get defunct, but xrdp still keeps record of them somehow and still tries to reconnect the user to an old connection that no longer exists. But I really don't understand the inner works of xrdp, this is just a wild guess from reading the logs and seeing a lot of defunct reconnectwm.sh processes. Is there a way to like make xrdp forget about the old session and just try and create a new one? I've found that the sockets are created under /run/xrdp/* , maybe deleting the respective sockets of those old connections would make xrdp create a new one? Best regards |
You can use the There's no way at the moment to get xrdp to forget about sessions. The state information is held in memory by What do you mean by 'defunct reconnectwm.sh' processes? |
Do you think an upgrade to 0.9.22.1-2 could solve this problems? It's the version I have available at the EPEL repo. Are there breaking changes and configurations I need to change from 0.9.17? reconnectwm.sh is the script configured in ReconnectScript in sesman, I have the default one. Currently, I have 65 defunct (zombie) reconnectwm.sh processes, with 10 months 23 days of xrdp service running. Thanks! |
You shouldn't have any zombie reconnectwm.sh processes, let alone 65 of them. That suggests sesman is missing the I've done a bit of archeology, and this was fixed for v0.9.19 - see #2146, #2151, #2168. So an upgrade to 0.9.22.1 should help. As far as breaking changes go, here are the relevant release notes:- I can't see anything in there which I'd describe as a breaking change. However - you're the systems admin, so if it does break you'll be the one explaining why! Please look through the above yourself. I've been a systems admin myself, and I can see you've got a huge system there with no scope for down-time. Take all the usual precautions (including a rollback strategy, tested on a VM or desktop machine) and you should be fine. Please ask if you need any clarification from the release notes above. |
Thank you so much @matt335672 !! I'll try to find a maintenance window to do the update during a weekend. It's a VM, so a snapshot should be fine in case we need to rollback. Best regards! |
xrdp version
0.9.17-2
Detailed xrdp version, build options
Operating system & version
CentOS Stream release 8
Installation method
dnf / apt / zypper / pkg / etc
Which backend do you use?
Xvnc
What desktop environment do you use?
Xfce
Environment xrdp running on
VM
What's your client?
Microsoft's official client
Area(s) with issue?
Session manager (sesman)
Steps to reproduce
Sometimes users try to reconnect to a session and they are unable to.
I can see that reconnectwm.sh is defunct.
✔️ Expected Behavior
User is able to reconnect
❌ Actual Behavior
User is unable to reconnect and prompted with a message like:
After a long time, like a day, tipically users are able to connect again.
I can't restart xrdp or xrdp-sesman to solve the problem, since we have dozens of users connected and that would make them loose their work and it's very hard to accommodate such a maintenance window.
Anything else?
In xrdp-sesman.log I get logs like this:
The text was updated successfully, but these errors were encountered: