problem
consoleproxy.session.timeout is now honoured for noVNC console sessions (#12810, PR #13058), but VNC/RDP/AJAX-based console viewers still rely on a separate, hardcoded idle threshold: ConsoleProxy.VIEWER_LINGER_SECONDS (180 seconds), used by isFrontEndAlive() in ConsoleProxyVncClient, ConsoleProxyRdpClient, and ConsoleProxyNoVncClient.
This means the effective idle timeout for a console session now depends on which viewer/hypervisor path served it:
An admin who sets consoleproxy.session.timeout to, say, 30 minutes to keep long-idle sessions open will still see legacy VNC/RDP/AJAX sessions get dropped after 3 minutes — an inconsistency that's confusing and undocumented.
versions
ACS 4.20+ (any branch carrying the PR #13058 / equivalent noVNC timeout fix)
The steps to reproduce the bug
- Set the global setting
consoleproxy.session.timeout to a value well above 180000 ms (e.g. 1800000 ms / 30 minutes).
- Open a console session that uses the legacy VNC/RDP/AJAX path (e.g. a hypervisor or console mode that doesn't route through noVNC).
- Leave the session idle.
- Observe the session is torn down after ~180 seconds, not after the configured
consoleproxy.session.timeout.
- Compare against a noVNC console session under the same setting, which correctly honours the configured value.
What to do about it?
Derive VIEWER_LINGER_SECONDS from the same configured consoleproxy.session.timeout value (ConsoleProxy.sessionTimeoutMillis) instead of keeping it as an independent hardcoded constant, so all console viewer types (noVNC, VNC, RDP, AJAX) honour one single, consistently-configured idle timeout.
This was flagged during review of PR #13058 (#13058 (comment)) but deliberately left out of that PR's scope, since it's a noVNC-focused backport and touching isFrontEndAlive() for the legacy viewer types is a broader behavioural change that deserves its own review/testing pass.
problem
consoleproxy.session.timeoutis now honoured for noVNC console sessions (#12810, PR #13058), but VNC/RDP/AJAX-based console viewers still rely on a separate, hardcoded idle threshold:ConsoleProxy.VIEWER_LINGER_SECONDS(180 seconds), used byisFrontEndAlive()inConsoleProxyVncClient,ConsoleProxyRdpClient, andConsoleProxyNoVncClient.This means the effective idle timeout for a console session now depends on which viewer/hypervisor path served it:
consoleproxy.session.timeout(both viaConsoleProxyGCThreadand, since PR Backport: Honour consoleproxy.session.timeout for noVNC console sessions #13058, the WebSocket session's own idle timeout).consoleproxy.session.timeoutsetting.An admin who sets
consoleproxy.session.timeoutto, say, 30 minutes to keep long-idle sessions open will still see legacy VNC/RDP/AJAX sessions get dropped after 3 minutes — an inconsistency that's confusing and undocumented.versions
ACS 4.20+ (any branch carrying the PR #13058 / equivalent noVNC timeout fix)
The steps to reproduce the bug
consoleproxy.session.timeoutto a value well above 180000 ms (e.g. 1800000 ms / 30 minutes).consoleproxy.session.timeout.What to do about it?
Derive
VIEWER_LINGER_SECONDSfrom the same configuredconsoleproxy.session.timeoutvalue (ConsoleProxy.sessionTimeoutMillis) instead of keeping it as an independent hardcoded constant, so all console viewer types (noVNC, VNC, RDP, AJAX) honour one single, consistently-configured idle timeout.This was flagged during review of PR #13058 (#13058 (comment)) but deliberately left out of that PR's scope, since it's a noVNC-focused backport and touching
isFrontEndAlive()for the legacy viewer types is a broader behavioural change that deserves its own review/testing pass.