Bug 5737 - Fake "Someone is now shadowing your session" messages...
Summary: Fake "Someone is now shadowing your session" messages...
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Agent (show other bugs)
Version: 4.5.0
Hardware: PC Linux Ubuntu
: P2 Major
Target Milestone: 4.9.0
Assignee: Henrik Andersson
URL:
Keywords: focus_shadowing, ossman_tester, relnotes
Depends on:
Blocks:
 
Reported: 2015-12-02 21:23 CET by Jens Maus
Modified: 2017-11-01 11:27 CET (History)
4 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Jens Maus 2015-12-02 21:23:02 CET
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 Pierre Ossman cendio 2015-12-09 10:51:25 CET
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 Jens Maus 2015-12-09 13:19:51 CET
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 Samuel Mannehed cendio 2015-12-15 18:32:13 CET
(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 Torsten Kasch 2016-02-26 12:17:49 CET
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 Pierre Ossman cendio 2016-12-15 10:24:45 CET
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 Samuel Mannehed cendio 2017-10-12 16:33:30 CEST
Release notes are missing for this bug.
Comment 14 Samuel Mannehed cendio 2017-10-26 10:09:03 CEST
Release note was added in commit 32828
Comment 16 Pierre Ossman cendio 2017-11-01 09:58:17 CET
The mechanism with using log files is gone so there is no way this race condition can still occur.

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