Bug 7621 - Log when multiple sessions can't be kept on the same agent
Summary: Log when multiple sessions can't be kept on the same agent
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Bugzilla mail exporter
Depends on:
Reported: 2021-01-05 13:31 CET by Samuel Mannehed
Modified: 2021-03-09 14:22 CET (History)
0 users

See Also:
Acceptance Criteria:


Description Samuel Mannehed cendio 2021-01-05 13:31:16 CET
When multiple sessions for one user is allowed we try to keep these sessions on the same ThinLinc agent in order to avoid problems with for example shared homedirs and other software.

If the agent hosting an existing session for the user goes down and the user tries to create an additional session we allow the user to do so on a different agent.

While the fact that this happened can be deduced by carefully checking the logs, it would be nice if we could log this more clearly. A separate log line preferably.
Comment 1 Samuel Mannehed cendio 2021-01-05 13:35:09 CET
Depending on how bug 7619 gets resolved its possible that we might encounter this scenario under different circumstances.

If an agent with user sessions is removed from a subcluster config it will continue working for the existing sessions. Bug 7619 could get resolved in such a way that we allow users with multiple sessions to create new sessions on a different agent after the original agent was removed. In that case we need a clear warning in the log for that too.
Comment 2 Samuel Mannehed cendio 2021-01-15 14:53:18 CET
The scenario described in bug 7619 now has logging. There is however no logging yet when a new session is started on a different agent due to the first agent being down.

Adding logging for this might require some restructuring of the code. The logic for keeping sessions on the same agent (and the exception in bug 7619) resides in the loadbalancer at the moment. However, the loadbalancer doesn't know where the sessions actually end up being created, that would be in handler_newsession.

It would not be desirable to spread the knowledge of this decision spread across multiple modules. We would probably want to lift this logic out to reside in handler_newsession instead of in loadbalancer in the future.

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