xfreerdp screen script

--===============6997935700223207195==
Content-Type: multipart/alternative; boundary=089e014942246f5b3104eb07e7e1

--089e014942246f5b3104eb07e7e1
Content-Type: text/plain; charset=UTF-8

Hello All,

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:

1. I start up thin client as was explained above.  I confirm both SCREEN
scripts work fine separately.

2. 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.

3. 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.

4. 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 W7 logout 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.

I hope my explanation will serve the purpose of presenting all possible
details rather than to scare developers who potentially can help. Looking
forward to read some feedback. Thank you for your time.

--
Simon

--089e014942246f5b3104eb07e7e1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hello All,</p>
<p dir=3D"ltr">I&#39;m facing a problem with xfreerdp SCREEN session when a=
nother RDP client attempts to login to the same W7 host.</p>
<p dir=3D"ltr">In lts.conf I set up SCREEN_06 to run xfreerdp and SCREEN_07=
 to run ldm. I used standard xfreerdp script from &quot;screen.d&quot; dire=
ctory. By default clients boots into &quot;ldm&quot; session and, as expect=
ed, 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 t=
o some host, let us say &quot;W7.local&quot;. 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 do=
n&#39;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). </p>

<p dir=3D"ltr">After I checked SCREEN_06 and SCREEN_07 sessions separately =
I want to try mixing them up. The scenario is as follows:</p>
<p dir=3D"ltr">1. I start up thin client as was explained above.=C2=A0 I co=
nfirm both SCREEN scripts work fine separately.</p>
<p dir=3D"ltr">2. 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 &quot;ld=
m&quot; session. I use example with Remmina but it could be any other RDP c=
lient, even a built-in RDC client which I can run from some other W7 machin=
e. </p>

<p dir=3D"ltr">3. Right after I started new RDP session (with Remmina) over=
 already existed one (which runs on SCREEN_06) and logged in to the same us=
er 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 grow=
ing number of Winlogon + logonUI processes which eat all available RAM in m=
atter of few seconds.</p>

<p dir=3D"ltr">4. If I terminate RDP session to W7.local controlled by Remm=
ina and switch to SCREEN_06 I can see (as expected) login prompt where I ca=
n provide login credentials and successfully re-login to W7.local Once I&#3=
9;ve got session back on SCREEN_06 all those instances of Winlogon + logonU=
I processes get terminated one by one and normal CPU and RAM utilization ge=
ts recovered in about 1 minute. </p>

<p dir=3D"ltr">It doesn&#39;t seem to be a problem of xfreerdp. To check th=
is I logged in to &quot;ldm&quot;=C2=A0 session on SCREEN_07 (while not tou=
ching 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 c=
redentials. The 1st RDP connection gets preempted (xfreerdp process termina=
tes with status code 5) by the 2nd one as soon as I hit login button. It do=
esn&#39;t result in creation of a bulk of=C2=A0=C2=A0 winlogon + logonUI pr=
ocesses. I can preempt the 2nd session by the 1st one via logging in back i=
nto it.</p>

<p dir=3D"ltr">It looks like when I play with aforementioned 4-step scenari=
o, I observe race condition or some other attempt of xfreerdp screen script=
 to fight with the=C2=A0 fact that it got preempted by Remmina. It tries to=
 recover RDP session which results in creating new instance of winlogon + l=
ogonUI processes. This attempt fails (probably because it needs valid user =
credentials) and it goes to another iteration. These iterations are not sep=
arated in time and run one by one in uncontrolled manner.</p>

<p dir=3D"ltr">As possible workaround I tried to force restarting X after W=
7 logout by setting XINITRC_DAEMON to false in lts.conf and it helped... bu=
t there is one side effect which I&#39;m not happy about. When RDP session =
running on SCREEN_06 gets preempted by Remmina (or some other RDP client) i=
t results in restarting X (I assume because xfreerdp process terminates) an=
d in turn &quot;cold&quot; 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 authe=
nticated which results in termination of the xfreerdp process after some ti=
meout (about half a minute) and restarting X again. It keeps restarting X a=
bout twice per minute and every time it does that my console switches to SC=
REEN_06 ignoring the fact that I&#39;m currently working within ldm session=
 on SCREEN_07 and don&#39;t want to be interrupted. A possible fix would be=
 to=C2=A0 disable restarting of not authenticated xfreerdp session by timeo=
ut=C2=A0 or at least to make this timeout large enough... but I don&#39;t k=
now how it can be done.</p>

<p dir=3D"ltr">I hope my explanation will serve the purpose of presenting a=
ll possible details rather than to scare developers who potentially can hel=
p. Looking forward to read some feedback. Thank you for your time.</p>
<p dir=3D"ltr">--<br>
Simon</p>

--089e014942246f5b3104eb07e7e1--


--===============6997935700223207195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
--===============6997935700223207195==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_____________________________________________________________________
Ltsp-developer mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-developer
For additional LTSP help,   try #ltsp channel on irc.freenode.net

--===============6997935700223207195==--