Bug 7619 - New sessions still possible on a removed agent
Summary: New sessions still possible on a removed agent
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Samuel Mannehed
Keywords: frifl_tester, prosaic
Depends on:
Reported: 2021-01-05 09:22 CET by Pierre Ossman
Modified: 2021-01-19 08:44 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2021-01-05 09:22:03 CET
If users want to perform maintenance on an agent, or remove it permanently, we recommend removing that agent from the configuration and waiting out existing sessions. The idea being that this prevents new sessions from being created, and it will eventually be unused.

This works most of the time, but not always. When multiple sessions are allowed, we try to make sure all sessions end up on the same agent. This happens even if the agent has been removed from the configuration. So a user can keep adding new sessions to the agent we want to get out of the cluster, just as long as the user keeps at least one session alive at all times.

It is unclear if this is a desired behaviour or not. Multiple sessions per user is not a generally stable situation to begin with. However it gets worse if the user has those sessions spread out over multiple hosts (assuming the home directory is shared). So we really want all user sessions to be on the same machine.

On the other hand, this is not something we fully guarantee today. We only try to group the sessions. If the agent with the existing sessions is unresponsive, or fails to create a session, then we'll gladly create the new session on a different agent.
Comment 1 Samuel Mannehed cendio 2021-01-05 13:37:34 CET
I see that there are at least three options of how this should work:

 * Let the user keep creating sessions on the removed agent (like today). The 
   user is happy, but the sysadmin might be confused as to why new sessions start
   after the removal.

 * Prevent such users from creating any new sessions everywhere until the session
   on the removed agent is ended. This would require a good error message. The
   user will not be happy, but the behavior would be "safe" when regards to the
   principle of keeping multiple sessions on the same agent.

 * Let the user create new sessions on other agents. This would make the principle
   of keeping multiple sessions on the same agent a "best effort". See bug 7621
   for logging in these cases. The user will be happy in this case but might run
   into confusing issues in the session.

The situation we have right now is probably the worst option. I'm leaning towards that the last option of doing this "best effort" is the way to go.
Comment 5 Samuel Mannehed cendio 2021-01-14 17:26:08 CET
The user will now get a new session on a different agent in this scenario. This can cause the user to experience problems caused by having multiple sessions on different agents. However, the behavior of removing agents from the configuration is now reliable.
Comment 7 Samuel Mannehed cendio 2021-01-15 13:26:27 CET
I added a log warning for this scenario as well.
Comment 11 Samuel Mannehed cendio 2021-01-18 14:17:18 CET
I have now fixed the issues pointed out via email. Mostly this concerned simplifying the logic of getting the prioritized agents, but the log warning was also simplified.
Comment 13 Frida Flodin cendio 2021-01-19 08:44:21 CET
Tested on Ubuntu20.04.

Could reproduce on tl-4.12.0 and it works as described in comment #5 when installing nightly-build. Also made sure that the normal behavior works, that is a user gets new sessions on the agent where he/she has the most sessions. 

And the log message looks good, closing.

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