I've noticed that the "Curren Sessions" figure, as written to /var/log/thinlinc-user-licenses, often is too high. Currently, on my RHEL cluster, it says 5, even though I only have one single session.
This bug is critical when running VSM without a system.license, since then we have a hard limit of 1 user.
Does this happen both when running in HA mode and when running without HA enabled?
I'm not sure. I think I've seen this on non-HA system as well. I'll try to reproduce this with HA disabled.
Yes, I've been able to reproduce this with HA disabled: Currently, /var/log/thinlinc-user-licenses says 4, but I only have 3 sessions started. If restarting vsmserver, vsmserver.log says: Current number of users: 3 ...but /var/log/thinlinc-user-licenses still says 4.
I think I've fixed this now. Problem occured because the new sessionstore code didn't update the license log as often as the old code. I might have fixed bug 1262 as well, so please test what happends when running in HA mode.
Works when HA is disabled. Will test with HA as well.
I've been unable to reproduce the problem, even with HA. Seems to work good.
No, this is still a problem. After testing on my HA cluster, thinlinc-user-licenses says 5, and there are 5 sessions in /var/lib/vsm/sessions, even though all my started sessions have terminated.
Created attachment 97 [details] Last 300 lines of vsmserver.log on primary
Created attachment 98 [details] Last 800 lines of vsmserver.log on secondary
One interesting thing is this traceback, on the secondary: 2005-04-11 17:06:53 WARNING vsmserver.HA: Other node told us to remove session for user24, but our copy of session dat a does not concur 2005-04-11 17:06:53 DEBUG vsmserver.session: Verifying session for user24 on tlha-primary.localdomain 2005-04-11 17:06:53 WARNING vsmserver.HA: Session for user24 is OK. Telling other node. Traceback (most recent call last): File "/opt/thinlinc/modules/xmlrpcserver.py", line 54, in do_POST methodresponse=1 File "/opt/thinlinc/modules/xmlrpclib.py", line 918, in dumps data = m.dumps(params) File "/opt/thinlinc/modules/xmlrpclib.py", line 578, in dumps dump(v, write) File "/opt/thinlinc/modules/xmlrpclib.py", line 588, in __dump raise TypeError, "cannot marshal %s objects" % type(value) TypeError: cannot marshal <type 'NoneType'> objects
My guess is that the error lies in loadstatus_update_thread(). One problem with this function is that it's very long and complex: It's 127 lines, with as many as 8 different indentation levels.
It seems that the problem was that the data in sessionstore.dead_children was lost when vsmserver exited. Fixed in revision 1.178 of vsmserver.
Regarding the traceback in comment 11: On the other node, this was found in vsmserver.log: 2005-04-11 17:07:23 DEBUG vsmserver.HA: Trying to contact other node for session info transfer 2005-04-11 17:07:24 ERROR vsmserver.HA: Unexpected error trying to transfer session info to tlha-secondary.localdomain Traceback (most recent call last): File "/opt/thinlinc/vsm/HA.py", line 65, in HA_session_update_thread iI11 = oO0 . sessionchange ( iiiI11 ) File "/opt/thinlinc/modules/xmlrpclib.py", line 986, in __call__ return self.__send(self.__name, args) File "/opt/thinlinc/modules/xmlrpclib.py", line 1239, in __request verbose=self.__verbose File "/opt/thinlinc/modules/xmlrpclib.py", line 1027, in request headers ProtocolError: <ProtocolError for tlha-secondary.localdomain:9000/RPC2: 500 Internal error>
I'm still able to reproduce this bug, by stopping and starting vsmserver & heartbeat, and at the same time doing logins. The problem seems to be less severe now, though, and it only happens if you are trying hard to reproduce this. The number of current sessions is corrected when vsmserver is restarted. This shouldn't be critical for 1.4.0.
Hmm.. this might be a bit hard to track down. Doing a rough time estimation.
moving from 'mediumprio' to '--', close?
We haven't seen this in ages and the code received a major rewrite back in 2.0. Closing.
