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.
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.
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!.
(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
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.
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.
Release notes are missing for this bug.
Release note was added in commit 32828
The mechanism with using log files is gone so there is no way this race condition can still occur.
