The main app has been running since some time in 2015, and there has been numerous sessions since, but session 12774 has been running since apparently yesterday. Most amazing is the 0:00 time running. Looks like a bug somewhere on the host.
What I usually do is to kill manually the rogue sessions. But it should be possible to automate the process with a shell.
So the behaviour might not be limited to standalone web apps but also affect cgi.
In a standalone app, however, sessions can’t be killed manually via shell AFAIK.
You could try to give a few circumstances where the problem is most likely to happen?
It would perhaps also remove any plugins.
Maybe this is more likely to occur with real concurrent users, rather than with an individual test. For example, maybe the problem occurs if a user closes its session at the same time another opens a session or closes a session?
The curious thing is that the session remains in memory while the client is destroyed and that there’s no session properties in the code. It is worrying that the next cleanup process fails to destroy these objects, because there may be many sessions in one day! And some database connections are not closed properly.
The main app has been running since some time in 2015, and there has been numerous sessions since, but session 12774 has been running since apparently yesterday. Most amazing is the 0:00 time running. Looks like a bug somewhere on the host.
What I usually do is to kill manually the rogue sessions. But it should be possible to automate the process with a shell.[/quote]
What you’re looking at there has nothing to do with sessions. That’s just a Perl script which happens to have sent a request to your app at some time in the past.
As for the app itself never quitting, that could be caused by a number of things, including sessions staying open, or just simply that you set app.autoquit to false. Usually though, web apps and sessions not closing is a result of a memory leak due to a circular reference somewhere.