Summary: | Input can be blocked if client hangs while shadowing | ||
---|---|---|---|
Product: | ThinLinc | Reporter: | Samuel Mannehed <samuel> |
Component: | VNC | Assignee: | Pierre Ossman <ossman> |
Status: | CLOSED FIXED | ||
Severity: | Normal | Keywords: | relnotes, upstream |
Priority: | P2 | ||
Version: | trunk | ||
Target Milestone: | 4.19.0 | ||
Hardware: | PC | ||
OS: | Unknown | ||
Acceptance Criteria: |
MUST:
* If the client for a shadower or regular user stops communicating with the server, the remaining connected user should have full control over the input in the session
|
||
Bug Depends on: | 8485 | ||
Bug Blocks: |
Description
Samuel Mannehed
This has been resolved upstream in TigerVNC: https://github.com/TigerVNC/tigervnc/pull/1718 It probably doesn't matter if the shadower or the original user disconnects. Note however that we have only tested disconnecting the original user. To clarify, the issue is actually not about disconnects. If either client disconnects, then everything works just fine. The issue is when either client hangs. Either because the software has locked up, or because the network abruptly stops working. You can easily simulate this by sending a SIGSTOP to a client's ssh process. Verified that I could see the issue with ThinLinc 4.18.0 on RHEL 10 beta. Tried stopping both the regular client, and the shadowing. After upgrading to build 3926, control is returned to the other client after a few seconds. Again, tested both the regular and shadowing client. All done.
> MUST:
>
> * If the client for a shadower or regular user stops communicating with the server, the remaining connected user should have full control over the input in the session
Indeed, after a bit of a delay. The delay can be annoyingly long, but the trade-off was to avoid false triggers. An unresponsive client should hopefully be rare, so I think this is a good compromise.
|