Unable to reconnect - reconnectwm.sh defunct about xrdp HOT 6 CLOSED

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 : 5900 + $D
VNC X11 TCP port : 6000 + $D

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?

from xrdp.

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

from xrdp.

You can use the xrdp-sesadmin command to list the sessions that xrdp knows about. On your version of xrdp however it's very clunky, and you'll need to authenticate with a username and password. It should however, let you tie up usernames with sessions.

There's no way at the moment to get xrdp to forget about sessions. The state information is held in memory by xrdp-sesadmin.

What do you mean by 'defunct reconnectwm.sh' processes?

from xrdp.

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!

from xrdp.

You shouldn't have any zombie reconnectwm.sh processes, let alone 65 of them. That suggests sesman is missing the SIGCHLD signals from these processes.

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:-

• v0.9.22.1
• v0.9.22
• v0.9.21.1
• v0.9.21
• v0.9.20
• v0.9.19
• v0.9.18.1
• v0.9.18

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.

from xrdp.

Thank you so much @matt335672 !!
This host is for accessing a very costumized htcondor cluster for our users, so it's very crowded 😄

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!

from xrdp.