Bugzilla – Bug 1263
"Current Sessions" is often too high
Last modified: 2017-04-04 12:41:19
You need to
before you can comment on or make changes to this bug.
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
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
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 an attachment (id=97) [details]
Last 300 lines of vsmserver.log on primary
Created an attachment (id=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
2005-04-11 17:06:53 WARNING vsmserver.HA: Session for user24 is OK. Telling
Traceback (most recent call last):
File "/opt/thinlinc/modules/xmlrpcserver.py", line 54, in do_POST
File "/opt/thinlinc/modules/xmlrpclib.py", line 918, in dumps
data = m.dumps(params)
File "/opt/thinlinc/modules/xmlrpclib.py", line 578, in dumps
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
2005-04-11 17:07:23 DEBUG vsmserver.HA: Trying to contact other node for session
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
File "/opt/thinlinc/modules/xmlrpclib.py", line 1027, in request
ProtocolError: <ProtocolError for tlha-secondary.localdomain:9000/RPC2: 500
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.