Unexpected session timeouts, RT 3.6.5

RT Users
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve just set up RT 3.6.5 for testing with a copy of the current
database from our old 3.4.1 install, and ran the usual update scripts
on the new copy.

The new version seems to have an issue with sessions timing out
unexpectedly, visible in Safari 2, Safari 3 and the current Firefox.
Basically, after logging in, one can click around constantly for
anywhere from a few seconds to a couple of minutes, but eventually
will be dumped back to the login screen. I’ve seen this both with
normal use and with frequent random clicking on links attempting to
generate the error.

Has anyone else seen this behaviour? Any thoughts on what might be
causing it? My rt.log file is set to log at debug level, but nothing
at all shows up when this error occurs.

Matt Pounsett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHPJtQmFeRJ0tjIxERAgpxAJ9gKIEmL7eJYvSmSqIUeKgHhLVfbQCgjj0Z
K8wAgMdyXZy6qM0Dfgd3gdU=
=I3xI
-----END PGP SIGNATURE-----

2

Hi Matt,

which session handling you use? In your RT_SiteConfig.pm, have you commented
out:

Set($WebSessionClass , ‘Apache::Session::File’);

??? I had several problems if i use this (two webservers, load balanced,
shared directory) so i switched to the normal and store the sessions inside
the DB

Torsten2007/11/15, Matt Pounsett matt.pounsett@cira.ca:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve just set up RT 3.6.5 for testing with a copy of the current
database from our old 3.4.1 install, and ran the usual update scripts
on the new copy.

The new version seems to have an issue with sessions timing out
unexpectedly, visible in Safari 2, Safari 3 and the current Firefox.
Basically, after logging in, one can click around constantly for
anywhere from a few seconds to a couple of minutes, but eventually
will be dumped back to the login screen. I’ve seen this both with
normal use and with frequent random clicking on links attempting to
generate the error.

Has anyone else seen this behaviour? Any thoughts on what might be
causing it? My rt.log file is set to log at debug level, but nothing
at all shows up when this error occurs.

Matt Pounsett

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHPJtQmFeRJ0tjIxERAgpxAJ9gKIEmL7eJYvSmSqIUeKgHhLVfbQCgjj0Z
K8wAgMdyXZy6qM0Dfgd3gdU=
=I3xI
-----END PGP SIGNATURE-----

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll
take
up to 20 percent off the price. This sale won’t last long, so get in touch
today.
Email us at sales@bestpractical.com or call us at +1 617 812 0745.

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

MFG

Torsten Brumm

http://www.torsten-brumm.de

3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matt,

which session handling you use? In your RT_SiteConfig.pm, have you
commented out:

Set($WebSessionClass , ‘Apache::Session::File’);

??? I had several problems if i use this (two webservers, load
balanced, shared directory) so i switched to the normal and store
the sessions inside the DB

Thanks for the response, Torsten.

I make no reference to any session handling configuration in my
RT_SiteConfig, so the default should be active. I’m assuming that’s
the database. I’m not using any load balancing though… the RT
server is stand-alone, with the database local, so I wouldn’t expect
any problems with session synchronization.

I’ve done some header capture to demonstrate the problem, but so far
I haven’t had any luck in tracking down where in the code it’s
happening.

In my paste below I show two requests captured using LiveHTTPHeaders
in Firefox. The two requests are only 1 second apart, but you can
see from the second response that RT has either decided to expire the
session in use, or has lost it entirely. As noted before, even at
‘debug’ level, RT doesn’t log anything when this happens.

Matt

http://rt.foo.com/Search/Build.html

GET /Search/Build.html HTTP/1.1
Host: rt.foo.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:
1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Accept: text/xml,application/xml,application/xhtml+xml,text/
html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: Foo.com
Cookie: RT_SID_CIRA.80=51e2f85a9b368158a5da550f106e6a14

HTTP/1.x 200 OK
Server: Apache
Pragma: no-cache
Cache-Control: no-cache
Keep-Alive: timeout=5, max=94
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

http://rt.foo.com/Search/Simple.html

GET /Search/Simple.html HTTP/1.1
Host: rt.foo.com
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:
1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Accept: text/xml,application/xml,application/xhtml+xml,text/
html;q=0.9,text/plain;q=0.8,image/png,/;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: Foo.com
Cookie: RT_SID_CIRA.80=51e2f85a9b368158a5da550f106e6a14

HTTP/1.x 200 OK
Server: Apache
Pragma: no-cache
Set-Cookie: RT_SID_CIRA.80=e33d394fc26656ed41b13cc6c36900bb; path=/
Cache-Control: no-cache
Keep-Alive: timeout=5, max=95
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHQc56mFeRJ0tjIxERAmYaAJ9vEOFCyEd9dng1O5scmo/WiuKVZQCffTyA
b/Spuqee9v6dsCFKT4/qYWM=
=TdXr
-----END PGP SIGNATURE-----

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, so I’ve temporarily given up on trying to debug this. I’m
using the workaround of forcing RT back to using
Apache::Session::File, which has appeared to work.

For posterity, here’s everything I know about the problem along with
some environmental information, in case someone somewhere down the
road runs into the same thing and is interested in debugging it
further than I did.

So…

Using RT 3.6.5 built from Ports on FreeBSD 6.2-RELEASE-p8, built to
use FastCGI. This is a single web server (no load balancing) with a
single MySQL database on localhost.

The problem: It appears that RT is randomly ignoring the session
information returned to it by MySQL, and is initiating a new session,
which forces the user back to the login screen. The problem can be
reproduced by clicking around the interface until you are
unexpectedly presented with the login screen.

Watching HTTP headers:

Under normal behaviour, the web browser sends the session cookie to
the web server and it responds with no new cookie, and whatever
content was requested. Periodically it unexpectedly responds with a
new session cookie and the login page.

Watching MySQL query logs:

When RT unexpectedly presents the user with a login page, the query
logs show that RT has done a lock, then select for the session ID, an
unlock, as usual… but then it inserts a new session row as if the
query for the old session ID had failed. Manually running this query
at this time succeeds and returns the session data.

Watching RT error log:

Set to debug level, the RT error log shows nothing when this happens.

Watching web server error logs:

The web server error logs also show nothing out of the ordinary when
this occurs.

I did some digging into the db-based session handling in order to
drop in some overrides in ./rt3/local to add debugging output, but
didn’t get very far before trying the workaround mentioned at the
beginning of this email. Since that workaround is sufficient for my
uses here, I’m sticking with it for now and abandoning further
debugging. However, if anyone (Jesse?) has some suggestions I’m
happy to try them out and report back the results.

Matt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFHRJ1AmFeRJ0tjIxERAqiQAJ4tDwIzGCEh1grFU06MtRHrxQj3dgCgi1/m
g570Gs2e1MjP7OW7dxkUhrs=
=Snks
-----END PGP SIGNATURE-----