XRDP Zombie Session

[darkworks]

I have noticed on strange issue with XRDP so i thought should report it.

first xrdp built version : 0.19.7

so i have none root xrdp user rdp_user which i use instead of root account . i connected to my machine and then in middle internet disconnect , as so as connection to xrdp interrupted. Now when i connect back to xrdp i get pure black screen with cursor. seems like old session is still kept due to which am getting black screen, so after that i login to xrdp via root account and i got access then i restarted xrdp service systemctl restart xrdp.service. after that i connected again to rdp_user account and this time i got access mean no black screen but my opened stuff become invisible like my chrome browser sessions note pad terminal etc , although i run htop and noticed that they are running but not visible on explorer UI after restart of xrdp service. after that i had to restart entire machine because i was not able to terminate and restart my chrome session because they were already running

so please fix the issue to auto terminate inactive session like after 5 minute and logout it auto.
also in linux commands with which i can see if any xrdp session still exists and maybe i just terminate it from root account instead of reboot xrdp service

thanks

[matt335672]

Hi @darkworks

You can auto-terminate your disconnected sessions by setting DisconnectedTimeLimit in /etc/xrdp/sesman.ini. This only works for Xorg based sessions at the moment.

There's a utility called xrdp-sesadmin which can list your xrdp sessions, but it's fiddly to use. It's easier to search the output of ps -ef for Xorg processes with display numbers of 10 or higher.

Does that answer your questions?

[darkworks]

Hi @darkworks

You can auto-terminate your disconnected sessions by setting DisconnectedTimeLimit in /etc/xrdp/sesman.ini. This only works for Xorg based sessions at the moment.

There's a utility called xrdp-sesadmin which can list your xrdp sessions, but it's fiddly to use. It's easier to search the output of ps -ef for Xorg processes with display numbers of 10 or higher.

Does that answer your questions?

ok thanks i had build xorg with xrdp so will check and set settings of sesman.ini

[darkworks]

Am just curious why by default KillDisconnected is set to false by default ?? as if you disconnected somehow upon reconnect you will land on black screen with cursor so why not set this flag to true by default

[matt335672]

When you reconnect you should end up with your old session. This supports use-cases like disconnecting from a session and then reconnecting to it later, possibly from an entirely different client.

[darkworks]

When you reconnect you should end up with your old session. This supports use-cases like disconnecting from a session and then reconnecting to it later, possibly from an entirely different client.

ok cool however i not understand the difference.
so i use mRemoteNG app to connect to my xrdp vps. I connect do my work and i close connection through this mRemoteNG app by simply clicking x button on top right. after that i can reconnect to it normally. However if i not press mRemoteNG app that top left x button to close connection incase where my internet connection went down for some reason. then when i connect to my machine i end up with black screen with cursor.
So Question is what is the difference between these two scenarios by pressing mRemoteNG x button what it send to xrdp server that it close connection.

so am wondering what will be the correct fix for the 2nd scenario where internet disconnected and connection is not properly closed and on reconnect user land on backscreen with cursor.

thanks

[matt335672]

There's a long-standing bug where you can't connect to a session which already has a client hung off it. We're working on architectural changes to fix this, but they're pretty major.

If you close the VPN first, there's no way for the TCP RST packet to get back to xrdp, and so the session stays open.

You can work around this by enabling TCP keepalives and configuring the OS to send more regular keepalive probes than the default.

For more info, see #1188, and in particular this post