[
https://issues.apache.org/jira/browse/GUACAMOLE-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18018894#comment-18018894
]
David S. Jones edited comment on GUACAMOLE-2118 at 9/8/25 8:34 PM:
-------------------------------------------------------------------
I think this might be related to something we found last week. And might be
related to GUACAMOLE-2081
Our implementation is pretty custom, we use our own web server and client
wrapper. We found that occasional the session would be closed with the message
back to the browser
!image-2025-09-08-15-11-59-435.png!
and the same "User is not responding." in the log
We found that FireFox reliably sends the 5sec nop/keepalive message but Chrome
and Edge, when minimized or mostly occluded, would drop back to 37sec for
Chrome and 60sec for Edge and the 15sec timeout would expire.
It appears that the 1.5.3 guacd (that we are upgrading from) did NOT enforced
that timeout!
We experimented some with generating a "nop" message from our intermediary but
found we would need a 'sanity check escape', and because of our potentially
complex connectivity, we decided we'd just increase the timeout in quacd. We
tried 60sec but found that 'too on the edge for Edge' and bumped it to 65sec
which appears to be working very well (Sessions live for many days)
#define GUACD_TIMEOUT 65000
was (Author: jonesds):
I think this might be related to something we found last week. And might be
related to GUACAMOLE-2081
Our implementation is pretty custom, we use our own web server and client
wrapper. We found that occasional the session would be closed with the message
back to the browser
!image-2025-09-08-15-11-59-435.png!
We found that FireFox reliably sends the 5sec nop/keepalive message but Chrome
and Edge, when minimized or mostly occluded, would drop back to 37sec for
Chrome and 60sec for Edge and the 15sec timeout would expire.
It appears that the 1.5.3 guacd (that we are upgrading from) did NOT enforced
that timeout!
We experimented some with generating a "nop" message from our intermediary but
found we would need a 'sanity check escape', and because of our potentially
complex connectivity, we decided we'd just increase the timeout in quacd. We
tried 60sec but found that 'too on the edge for Edge' and bumped it to 65sec
which appears to be working very well (Sessions live for many days)
#define GUACD_TIMEOUT 65000
> unable to upgrade 1.5.5 to 1.6.0 due to sporadic hanging issue
> --------------------------------------------------------------
>
> Key: GUACAMOLE-2118
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2118
> Project: Guacamole
> Issue Type: Bug
> Affects Versions: 1.6.0
> Reporter: Jason Keltz
> Priority: Major
> Attachments: guacamole-logs.txt, guacd-178388-gdb.txt,
> guacd-178388-lsof.txt, guacd-240326-gdb.txt, guacd-240326-lsof.txt,
> image-2025-09-08-15-11-59-435.png
>
>
> I've been running Guacamole since around 2020, upgrading reasonably quickly
> each and every time there's been an update. I update my Tomcat to the latest
> 9.X release from time to time (currently 9.0.102) , and my JDK to the latest
> 8.X release from time to time (currently jdk8u452-b09).
> Recently, after attempting an upgrade from Guacamole 1.5.5 to 1.6.0, I ran
> into a problem. Initially, everything seemed to work just fine. I can
> connect to any of the systems I have available. However, at some point
> later, I notice in the tomcat logs a lot of "connects" and "disconnects" to
> hosts. Users start complaining that "Guacamole isn't working". What I
> noticed at this point was that when they would try to return to a connection,
> it would connect, and their existing connecting would start to redraw, but
> it would hang in the middle. If I restart guacd at this point, it starts to
> work again, but the problem comes back. Some users would see it. Other users
> were fine.
> I feel like there's a bug hiding, and it may require a lot of user activity
> to get to it. I ended up creating a devel system for testing, and I'm
> running guac 1.6.0 there, and I've enabled full debugging, but I can't seem
> to make it happen here yet. Is there any easy way I can force a bunch of
> connections? The devel system is running labtest Rocky 8.10 (RHEL8.10) with
> latest kernel and patches and this matches the production system. They are
> both installed with the same kickstart configuration.
> I'm opening this "bug" even though I don't have concrete information yet. If
> I really have to do it, I may have to re-install on the production system to
> get the debugging information that I need, but I'd rather not do it if not
> necessary since it causes user inconvenience, and Guacamole is an important
> part of our educational environment.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
