cleaning up CSP sessions (aka where/who/what is the %CSP.Daemon?)

Question

Question

Laura Cavanaugh · Sep 9, 2016

#Change Management #Security #Management Portal #Caché

I know %CSP.Daemon is supposed to clean up old CSP sessions (?). In my management portal, under System/ License Usage, I see 33 "Units" used (and there are 33 licenses in use), but usernames from old IP address and that are not being used. Their active times are often in the millions of seconds. They are not "on" the system right now.

At most, only 3 users are on the system right now.

Are these supposed to be cleaned up? Can I clean them up programmactially, and how would I know if they're not active?

Thanks,

Laura

Discussion (8)0

Log in or sign up to continue

Sean Klingensmith · Sep 9, 2016

Hello Laura,

Do you see any CSP Sessions active under [System Operation]->[CSP Sessions]? The CSP.Daemon will end any sessions (and release the associated license) after the session times out. The timeout for each session will be displayed on this page. You can also manually end sessions.

If the license is remaining after the CSP Session is ended, or if the session remains after it is supposed to be timed out this would indicate a problem with the session reclamation. Otherwise, it could be an issue with an excessively long session timeout (this can be configured in the CSP Application).

0 0

Sean Klingensmith · Sep 9, 2016

Hello Laura,

The CSP.Daemon will use the CSP Event classes (there can be more than one) associated with the session (this information is stored in the ^%cspSession global). It will default to the value of the Event Class setting in the CSP Application, but, as you know, it can also be set programmatically.

/isc/studio/usertemplates/ is a CSP Application used by Studio to display certain dialogs. I don't believe we take a license for these sessions, but they should still time out.

It looks like the CSP.Daemon is failing to end these sessions. This investigation might get a fairly involved. I definitely recommend contacting the WRC with the information mentioned above.

0 0

score 0 · Answer 1 · 2016-09-09T10:55:42-04:00

Hi Sean,

Yes, there are 241 csp sessions, and all but 9 have timeouts in the past. I have been working on logouts and sessions, and have changed things in the code, but the default timeout was always 3600 at most (set in the web application), and now it's 45*60 (45 minutes), set in the code.

How do I clean these up? If I can at least clean them up, I can see if the current logout code will reclaim sessions/licenses.

score 1 · Answer 2 · 2016-09-09T11:11:46-04:00

The CSP.Daemon should close any session with a timeout in the past. Do you have CSP Events class? In my experience, the most common cause of problems like this is a misbehaving OnTimeout or OnEndSession callback, but there could be other causes.

If there isn't anything obviously wrong with the callback code, I suggest you open a WRC case to investigate this.

Regards,

Sean Klingensmith

score 1 · Answer 3 · 2016-09-09T11:21:00-04:00

Yes, we have had a SessionEvents class, since before I took over logouts and sessions.

I have since had the user logout with ?CacheLogout=end, which calls OnEndSession in the sessionevents class, which then calls Do ##class(%ZEN.Controller).OnEndSession() per the documentation. I do a little cleanup in OnEnsSession, too, but nothing worth noting ( a little temp global cleanup ) (ok, so I just noted it).

Yes, before I took over this, the OnEndSession actually set EndSession = 0; I don't think we knew what to do.

But NOW, wouldn't the Daemon just clean stuff up?

Say, am I logging out correctly now and ending everything? That is, as log as the user logs out. If he just closes the browser (you can never really stop them from doing this), what happens to the session and to the license?

Thanks

Laura

score 0 · Answer 4 · 2016-09-09T12:47:23-04:00

Hello Laura,

If the user logs out with CacheLogout=end, or %session.EndSession=1, the session will end OnEndSession callback will be called and the session will be terminated immediately, and the license will be released. This will be done in the CSP server process, not the CSP.Daemon.

If the user closes the window (or just walks away from the computer), the session and the license will remain until the session timeout is reached. This is done by the the CSP.Daemon, which will periodically wake up and look for sessions that have expired, and end them. Setting EndSession=0 in the callback would prevent the session from being ended. As long as this has been removed, I agree, the CSP.Daemon should be cleaning these sessions up.

Are you able to end any of these sessions through the Management Portal page? (I'm not recommending deleting all of them, this is just a diagnostic test).

If you open a WRC Case, I recommend sending:

1) a Buttons report

2) an export of the Session Events class (just in case)

3) an export of the ^%cspSession global:

do $system.OBJ.Export("%cspSession.gbl","/tmp/cspSession.xml")

score 0 · Answer 5 · 2016-09-09T13:03:46-04:00

We set the SessionEvents class programmatically. When I end a session via management portal, it does not end. Sometime it sets the Timeout to NOW (UTC time) but it's still in the list of CSP Sessions in mgmt portal.

I can see the application it's using, so I set the SessionEvent class in the web application to our SessionEvent class, (sounds redundant but it's not), then tried to end it again. It's still there.

There are some sessions using the web application /isc/studio/usertemplates/ with a timeout of 2016-08-30 17:30:41.

Does the CSP.Daemon try to run our own SessionEvents class? Are there settings for this somewhere?

Thanks,

Laura

score 0 · Answer 6 · 2016-09-09T16:34:54-04:00

Thanks Sean. Jonathan at IS did call me today, and we discussed sessions. I found that I had been timeing users out incorrectly, but that i'm doing it correctly now.

We decided that I would set the Events Class to my session events class for all the web applications that we're using.

The problem is that I did that, but the sessions still dont' seem to be timing out. I began to play with the session object at a terminal window (for future reference, it's the %CSP.Session class, and it's persisten). I was not able to edit a session object with ID = SessionId, because of an error. I think this may be causing a lot of problems on our end.

Yes, IS will have to help with this.

Thanks!

Laura