www.cendio.com
Bug 5737 - Fake "Someone is now shadowing your session" messages...
: Fake "Someone is now shadowing your session" messages...
Status: CLOSED FIXED
: ThinLinc
VSM Agent
: 4.5.0
: PC Linux Ubuntu
: P2 Major
: 4.9.0
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2015-12-02 21:23 by
Modified: 2017-11-01 11:27 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2015-12-02 21:23:02
On our ThinLinc server it sporadically happens that after a while users are
presented fake "Someone is now shadowing your session..." messages when they
login to our server to resume an already existing session. 

Because we currently have no idea to resolve/fix or debug this problem we have
to reboot the ThinLinc server to resolve the issue. Thus I would like to ask
here how we can debug this situation to find out why ThinLinc is thinking that
the sessions are being shadowed while at that time this is definitly not the
case.

This problem also existed already in ThinLinc 4.4.x.
------- Comment #2 From cendio 2015-12-09 10:51:25 -------
This can happen if the user happens to shadow themselves. Clients without local
devices will not be thrown out when another client connects. So it is possible
for the user to be connected with multiple clients at the same time. This will
be detected as a shadowing and the notification will pop up.

The user's xinit.log should tell more about what's going on. Could you attach
it here? Or send it to our support email if you wish to keep it private.
------- Comment #3 From 2015-12-09 13:19:51 -------
The user is definitely not actively shadowing himself. And what do you mean by
"Clients without local devices will not be thrown out"?. Here we are using
ThinClients which will automatically be shut down each night to save energy.
This shutdown is a hard shutdown of the ThinClient OS being used (thinstation).
User might, however, continue to work from home or over the weekend and try to
resume their sessions from devices at home. Could this already be a problem?

Regarding the xinit.log, I don't actually know which one I should send you
because here I can see that the specific user currently has 6 different
xinit.log logfiles in his /var/opt/thinlinc/sessions/USERNAME directory:

./5/xinit.log
./3/xinit.log
./3.ended/xinit.log
./12/xinit.log
./1/xinit.log
./2.ended/xinit.log

So please try to explain me which one you are interested in or how to debug
this situation. I still don't get it why ThinLinc seems to think that session
shadowing is active while it is NOT!.
------- Comment #4 From cendio 2015-12-15 18:32:13 -------
(In reply to comment #3)
> And what do you mean by "Clients without local devices will not be thrown out"?

When a user connects to an existing session which doesn't have any local
resources enabled (such as audio, local drives, local printers etc.) the
existing connection will remain. See bug 2251. Normally the new connection will
terminate the old one.

> Regarding the xinit.log, I don't actually know which one I should send you
> because here I can see that the specific user currently has 6 different
> xinit.log logfiles in his /var/opt/thinlinc/sessions/USERNAME directory:
> 
> ./5/xinit.log
> ./3/xinit.log
> ./3.ended/xinit.log
> ./12/xinit.log
> ./1/xinit.log
> ./2.ended/xinit.log
> 
> So please try to explain me which one you are interested in or how to debug
> this situation.

We are interested in the xinit.log from a session in which the user has seen
the fake shadowing message. If it doesn't happen in all sessions ask your user
to alert you as soon as it happens again and ask him to not login again until
you have taken /var/opt/thinlinc/sessions/USERNAME/last/xinit.log
------- Comment #5 From 2016-02-26 12:17:49 -------
We've experienced exactly the same behavior on Fedora 23. But unfortunately I
discovered this Bugzilla entry shortly after I told the affected user to log
out and in again earlier today in order to make the message go away, so I
cannot provide a session log right now. I'll do so as soon as it happens again.
------- Comment #9 From cendio 2016-12-15 10:24:45 -------
We'll try to solve the issue in comment 7, e.g. by using a better mechanism
than parsing log files and assume that it also solves the original issue.
------- Comment #13 From cendio 2017-10-12 16:33:30 -------
Release notes are missing for this bug.
------- Comment #14 From cendio 2017-10-26 10:09:03 -------
Release note was added in commit 32828
------- Comment #16 From cendio 2017-11-01 09:58:17 -------
The mechanism with using log files is gone so there is no way this race
condition can still occur.