I'm facing a problem with xfreerdp SCREEN session when another RDP client attempts to login to the same W7 host.
In lts.conf I set up SCREEN_06 to run xfreerdp and SCREEN_07 to run ldm. I used standard xfreerdp script from screen.d directory. By default clients boots into ldm session and, as expected, I can switch to SCREEN_06 at any time. The first time I switch into it from ldm I can see start up of X followed by start up of xfreerdp session to some host, let us say W7.local. I can login on that W7.local host without any problems. To be more specific: both LTSP and that W7.local are virtual machines running on ESXi 5.5 with VMware Tools installed (I don't think that virtualized nature of both hosts can make any difference but I found some info that VMXNET3 network driver, used by both hosts, has some issues with RDP).
After I checked SCREEN_06 and SCREEN_07 sessions separately I want to try mixing them up. The scenario is as follows:
I start up thin client as was explained above. I confirm both SCREEN scripts (i.e. RDP and ldm) work fine separately.
While having SCREEN_06 session connected to W7.local via RDP I need (for some reasons, not discussed here) to RDP to the same host, i.e. W7.local from another client, say from Remmina running within ldm session. I use example with Remmina but it could be any other RDP client, even a built-in RDC client which I can run from some other W7 machine.
Right after I started new RDP session (with Remmina) over already existed one (which runs on SCREEN_06) and logged in to the same user account I can see the same session (started previously on SCREEN_06) on Remmina, but at the same time I can see about 100% CPU utilization and growing number of Winlogon + logonUI processes which eat all available RAM in matter of few seconds.
If I terminate RDP session to W7.local controlled by Remmina and switch to SCREEN_06 I can see (as expected) login prompt where I can provide login credentials and successfully re-login to W7.local Once I've got session back on SCREEN_06 all those instances of Winlogon + logonUI processes get terminated one by one and normal CPU and RAM utilization gets recovered in about 1 minute.
It doesn't seem to be a problem of xfreerdp. To check this I logged in to ldm session on SCREEN_07 (while not touching SCREEN_06 at all after reboot, so it sits idle without even running X) and ran 2 xfreerdp sessions one by one. By running RDP session I mean not only to connect to RDP host but also to login into it with the same user credentials. The 1st RDP connection gets preempted (xfreerdp process terminates with status code 5) by the 2nd one as soon as I hit login button. It doesn't result in creation of a bulk of winlogon + logonUI processes. I can preempt the 2nd session by the 1st one via logging in back into it.
It looks like when I play with aforementioned 4-step scenario, I observe race condition or some other attempt of xfreerdp screen script to fight with the fact that it got preempted by Remmina. It tries to recover RDP session which results in creating new instance of winlogon + logonUI processes. This attempt fails (probably because it needs valid user credentials) and it goes to another iteration. These iterations are not separated in time and run one by one in uncontrolled manner.
As possible workaround I tried to force restarting X after logout from W7.local by setting XINITRC_DAEMON to false in lts.conf and it helped... but there is one side effect which I'm not happy about. When RDP session running on SCREEN_06 gets preempted by Remmina (or some other RDP client) it results in restarting X (I assume because xfreerdp process terminates) and in turn "cold" restarting of xfreerdp screen script (looks the same as you hit Ctrl+Alt+F6 for the first time after booting thin client). So far so good, but now we have SCREEN_06 RDP session started and not authenticated which results in termination of the xfreerdp process after some timeout (about half a minute) and restarting X again. It keeps restarting X about twice per minute and every time it does that my console switches to SCREEN_06 ignoring the fact that I'm currently working within ldm session on SCREEN_07 and don't want to be interrupted. A possible fix would be to disable restarting of not authenticated xfreerdp session by timeout or at least to make this timeout large enough... but I don't know how it can be done.
My goal is to implement a nice switching (without creating bult of winlogon + logonUI processes which consume all RAM and CPU cycles) between RDP session running on SCREEN_06 and RDP session (to the same host and to the same account) initiated by another client (Reminna in ldm, or RDC on some Windows machine, or even aFreeRDP on my Android tablet).
Any help is greatly appreciated.