I have google'ed a lot on this question but haven't found an answer. I have a Guacamole server that connects to a local VNC session and I would like for it to disconnect the user session if it detects no activity for an hour.
What I've tried and attempted
used xprintidle to show idle time of the user, this works so will be put in a script that might be used later to terminate an idle session.
I have looked at Guacamole's api-session-timeout and set it for a minute, I had hoped it would not reconnect to the same session once the VNC server stops abruptly. It seems this did not work.
I have tried to use guacamole's user-mappings.xml to specify the parameter "autoretry" and set that to "1". Restarted and this did not work, I'm thinking its not used this way.
I have went to the guacamole postgres database and manually inserted the entry for autoretry into the parameter table. Restarted, but this did not work.
I have went to the VNC side (I use TurboVNC) and looked at the flag -idletimeout and configuration option max-idle-timeout. This terminates the TurboVNC service when there are no active connections. It is not what I am after, I'm trying to only disconnect the session when the user is idle.
I figured that the VNC side would not work because even if the VNC session is terminated Guacamole would keep on retying forever to reconnect to that session.
From some posts on the Guacamole mailing list it seems that disabling auto reconnect is not possible without a recompile from source.
Is there a way to disconnect an active session after an idle timeout period? or maybe a way to stop Guacamole from reconnecting?
Related
I am facing a strange problem. After a variable amount of time, my quickfixj session simply hangs without any error. The session seems to be locked because I cannot write anything to it (without exceptions on the log file) nor the server sends anything to me. The thread socket initiator shows that the sessions is logged in, but I cannot write anything on the socket because it seems to be locked.
Any suggestions?
TL;DR: Rails-server restarts aren't handled gracefully in Action Cable, resulting in corrupted state. How to fix that?
I run a Rails server which uses Action Cable, among other things.
When I change a file, the server restarts as expected. But it doesn't exactly restart gracefully.
The Action Cable connection logs {"type":"disconnect","reason":"server_restart","reconnect":true} in the established socket. Then the socket appears to be cut and my channel's unsubscribed method does not run. Upon reconnect, however, the subscribed method does run—as it should, but now we have an asymmetry. Something as simple as keeping track of the number of connected clients has become unreliable because upon a server restart that number will now double although the true number remained the same. That's because it gets to increment the count when subscribed is called, but decrementing the counter happens in unsubscribed, which is not called when the server restarts.
If this only happened in development, it wouldn't be a huge issue, but it happens in production as well during server restarts caused by deployments.
How do I tell Rails to restart the server gracefully, by which I mean it should also run the unsubscribed method in my channel instead of just cutting the connection?
EDIT: I've also filed an issue with Rails: https://github.com/rails/rails/issues/41005
Assume that I connected to the broker with "clean session=false" and started receiving events, in case of disconnection ideally my application will still receive data on connection. But if the application is crashed I want to have a fresh start and clear my session.
Can I clear my session on the MQTT broker and have a fresh start?
From the documentation I concluded that if I wanted to do that I would need to do the following:
application start
connect using "clean session=true" // this will cause any current session to be removed along with its data
every thing related to the session is purged from server
disconnect
connect using "clean session=false" and start getting the data.
I got the idea from
http://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment
"If clean session is set to true, the broker won’t store anything for
the client and will also purge all information from a previous
persistent session."
Is this the correct way to clear a previous session?
Yes, that is the only way to clear a session for a client.
I am having a bit of an issue where if the client crashes or if it loses connectivity it does not properly close the connection. This results in several idle connections that keep adding up. The client I am using rabbitmq-c does not support heartbeats yet therefore I cannot use that as a possible solution.
Is there anyway to kill off any connections that are not at the same time consuming a queue?
I found out the client was not setting a timeout time to the server therefore the connections were always being kept open. I also updated the client to support Heartbeats so there is now two ways the connections can be killed instead of being kept open.
Before I even start researching WFP I need to know one thing:
Can I detect an outbound TCP connection attempt, pause it until the user clicks Allow/Block, and then accordingly allow it to succeed or block it?
Other WFP based software such as Windows 7 Firewall Control always blocks the first connection attempt. Clicking Allow only applies to subsequent connection attempts. The first attempt always fails and the blocked application assumes there is no internet and I have to restart the application.
Is it possible to pause until Allow/Block is clicked in WFP or is my only option to write a kernel-mode driver?