2

user cannot connect to server over xrdp tested using linux remoted desktop client, as well as windows remote desktop client

error messages is "error: problem connecting"

/var/log/sesman.log

shows this error

[20170419-22:06:02] [INFO ] scp thread on sck 7 started successfully
[20170419-22:06:02] [INFO ] ++ reconnected session: username test, 
display :47.0, session_pid 2869, ip xxx.xxx.xxx.xxx:53732 - socket: 7

grepping for that process

root@server:/etc/xrdp# ps -aux | grep defunct
root      2869  0.0  0.0      0     0 ?        Z    19:08   0:00 
[xrdp-sessvc] <defunct>

trying to kill the process

kill -9 2869

does not kill the process

how do i kill this process?

users cannot log on to what the log file say is an existing session

however when run look to see disconnected tcp sessions (not established connections, but just listening ports) i do not see any session existing for that user

this is a chronic, reoccurring problem, that doesn't seem to manifest itself in any regular pattern

what can I do?

listing all xrdp sessions

#!/bin/bash

# find disconnect RDP sessions

lsof -b -w -n -c /^Xvnc$/b -a -iTCP:5900-5999

shows no disconnected sessions (all tcp connections are established for all users connected)

xrdp
  • 21
  • 1
  • 1
  • 2
  • 1
    I should note that the only things that seems to solve htis problem is restarting the xrdp server. I cannot do that as multiple users are logged on right now. – xrdp Apr 20 '17 at 03:23

3 Answers3

2

xrdp is making a log diary about the session inside .xrdp* files stored into the user's home directory. It might happen some .xrdp* session files to be stored into /tmp/ or /tmp/.xrdp/. xrdp service is making a relation with this session files. So, in order to make a connection again when you have defunct processes, you have three options:

  • to make a new connection using different resolution (works as a workaround, but I do not recommended it)
  • to remove .vnc/sessman* files from the home dir of the affected user/s, xrdp* files in /tmp and /tmp/.xrdp/ for affected user and connect again. (recommended solution)
  • to restart xrdp service which will clear up correlation with the session files. (recommended only if you can afford downtime of xrdp sessions :) )
miki
  • 21
  • 3
1

FOr anyone that comes across this issue, I found that xrdp server stores some state information about disconnected sessions. Even parsing all the TCP connections and killing the listening but not established ports does not solve this problem (although that does solve a huge problem of unnecessary resource allocation).

I found I cannot reap the zombies and force XRDP to create a new session instead of trying to reconnect to previous state, without restart XRDP server.

The only trick I found is to change the screen resolution of the client to trick the xrdp server into thinking it is a new machine. This allows the connection to be accepted and establishes a new session.

xrdp11aaaa
  • 11
  • 1
  • Additionally, xrdp (version 0.9.6) uses the requested screen resolution and color depth to determine if it should reconnect the same session. It used to be configurable (by manually choosing the specific tcp port of the existing session, e.g., 5901) back in v 0.6.something but they decided that was too much power for the users... – bgStack15 Aug 23 '18 at 12:00
0

A little late to the game, but why it does it I'm not sure, but my server with an uptime of only 7 months had thousands of defunct xrdp processes. I clean it up with "sudo systemctl restart xrdp.service".

Joseph C Hohl
  • 1