Version 3.6.1--dreaded infinite login

RT Users
1

I installed the 3.6.1 upgrade with great anticipation, fired up the
server, logged in, clicked on a link…and logged in again.

For me, looks like multiple logins are still not squashed. Details:

Mac OS X 10.4 server
perl 5.8.6
apache
Oracle 9i
using LDAP integration

Install history:

  • had 3.4.5
  • upgraded to 3.6.0
  • upgraded to 3.6.1rc2 #Thought maybe that would fix the login
  • upgraded to 3.6.1

Did I mess things up by running one of these upgrades? Should I run a
full install?

Anyone else still seeing multiple logins, or is something messed up on
my system?

Thanks,
Jim

Jim Brandt
Administrative Computing Services
University at Buffalo

2

At Wednesday 8/9/2006 10:51 AM, Jim Brandt wrote:

Anyone else still seeing multiple logins, or is something messed up
on my system?

Thanks,
Jim

Jim,

We’re still struggling with this, although I haven’t been able to try 3.6.

I have something that may be a workaround - I’d be curious to see if
it works for you. I put a static-html copy of the Login page on a
different web server from my RT instance. In that html page, I
changed the login form action from POST to GET, and I changed the
form’s action to the full URL of my RT instance. It seems to work OK -

Steve

3

At Wednesday 8/9/2006 10:51 AM, Jim Brandt wrote:

Anyone else still seeing multiple logins, or is something messed up
on my system?

Thanks,
Jim

Jim,

We’re still struggling with this, although I haven’t been able to try 3.6.

I have something that may be a workaround - I’d be curious to see if
it works for you. I put a static-html copy of the Login page on a
different web server from my RT instance. In that html page, I
changed the login form action from POST to GET, and I changed the
form’s action to the full URL of my RT instance. It seems to work OK -

There are two primary causes:

  1. An RT instance with multiple hostnames, such that when RT redirects
    to itself, it changes hostnames on the users
  2. A bug in Apache::Session’s statement handle caching that causes RT to
    silently obliterate users’ sessions, usually on redirect.

You might try backporting the new redirect code from 3.6.

Best,
Jesse

4

Jesse,
You mention "You might try backporting the new redirect code from 3.6. "
What code is this?

I had my Oracle dba do a database extract and imported it into mysql and
users who were experiencing the re-login, aren’t now…

5

Jesse,
You mention "You might try backporting the new redirect code
from 3.6. "
What code is this?

I had my Oracle dba do a database extract and imported it
into mysql and
users who were experiencing the re-login, aren’t now…

Interesting. I noticed I had this same re-login problem on my instance,
when I tried to change my configuration so that the database was used
rather than the filesystem for session tracking information. This was
in 3.4.1 code, with an Oracle backend. What I did was uncomment this
line:

Oracle => ‘Apache::Session::Oracle’,

in /path-to-your-RT/share/html/Elements/SetupSessionCookie. I was
hoping I would get a performance boost, and indeed, logging in and
having the home page load was faster, but any time I clicked on
anything, I had to log in again. So I reverted that change. Of course,
if you don’t use the DB for session management, $RT::MasonSessionDir is
used instead. All things being equal, if I dumped the data to MySQL, as
you did, I didn’t have any problems.

However, I thought some people who had the re-login issue had a MySQL
backend?

Eric Schultz
United Online

6

Mine is commented out and seem to experience the re-login only on the
first click. For example, after login, if the user just clicks Home, it
says they aren’t logged in.-----Original Message-----
From: Schultz, Eric [mailto:ESchultz@corp.untd.com]
Sent: August 09, 2006 10:23 AM
To: Don Beethe; rt-users@lists.bestpractical.com
Subject: RE: [rt-users] version 3.6.1–dreaded infinite login

Jesse,
You mention "You might try backporting the new redirect code from 3.6.

"
What code is this?

I had my Oracle dba do a database extract and imported it into mysql
and users who were experiencing the re-login, aren’t now…

Interesting. I noticed I had this same re-login problem on my instance,
when I tried to change my configuration so that the database was used
rather than the filesystem for session tracking information. This was
in 3.4.1 code, with an Oracle backend. What I did was uncomment this
line:

Oracle => ‘Apache::Session::Oracle’,

in /path-to-your-RT/share/html/Elements/SetupSessionCookie. I was
hoping I would get a performance boost, and indeed, logging in and
having the home page load was faster, but any time I clicked on
anything, I had to log in again. So I reverted that change. Of course,
if you don’t use the DB for session management, $RT::MasonSessionDir is
used instead. All things being equal, if I dumped the data to MySQL, as
you did, I didn’t have any problems.

However, I thought some people who had the re-login issue had a MySQL
backend?

Eric Schultz
United Online

7

Mine is commented out and seem to experience the re-login only on the
first click. For example, after login, if the user just
clicks Home, it
says they aren’t logged in.

What I think is interesting is that the problem goes away when you move
to MySQL :slight_smile:

Eric Schultz
United Online

8

Mine is commented out and seem to experience the re-login only on the
first click. For example, after login, if the user just clicks Home, it
says they aren’t logged in.
I had this behaviour with 3.6.1rc(1|2) but I just installed 3.6.1 and it
got worse.
Cleaned mason-cache ofcourse, did stop and start apache. Upon logging
into RT and clicking Home I was back at the login page. OK, normally the
solution was to goto Configuration, login in again, and from then on I
could go anywhere. This time I was presented with login again. So I
decided to click Configuration and than Queues, login again, and after
that is was gone.
I read somewhere that Apache::Session could be the culprit. So I upgrade
the rt-3.6.1 perl instance Apache::Session to 1.81. Did apache stop,
cleaned mason-cache, apache start and tried to login, got the Home page
and clicked Home again–> no loginbox ;-))) yeah.

Further config details:
RT-3.6.1
RTFM latest svn
AT latest svn
Oracle XE

Joop

Joop van de Wege JoopvandeWege@mococo.nl

9

Joop van de Wege wrote:

I read somewhere that Apache::Session could be the culprit. So I upgrade
the rt-3.6.1 perl instance Apache::Session to 1.81. Did apache stop,
cleaned mason-cache, apache start and tried to login, got the Home page
and clicked Home again–> no loginbox ;-))) yeah.

For my system, CPAN told me I was OK on Apache::Session at version 1.81
and the change log didn’t show any changes. I asked for updated modules
and it showed two new ones:

cpan> r

Package namespace installed latest in CPAN file
Apache::Session::Generate::ModUniqueId 0.01 0.02
MIYAGAWA/Apache-Session-Generate-ModUniqueId-0.02.tar.gz
Apache::Session::Generate::ModUsertrack 0.01 0.02
MIYAGAWA/Apache-Session-Generate-ModUsertrack-0.02.tar.gz

Strangely, if you look at http://search.cpan.org under Apache::Session,
it still shows these two modules at 0.01, even though 0.02 appears to
have been uploaded years ago. You can see version 0.02 by going to them
directly. The strange thing is that the only things listed in the change
log is a syntax error…

I ran the install for these two modules but I’m not sure it changed
anything.

If I quit the browser I consistently get prompted twice (login, click a
link, login again, then no more logins), sometimes three times.
If I keep the browser running and use just the ‘Logout’ button, it only
get prompted once, so logout/login appears to work correctly.

Anyone else have luck with an Apache::Session upgrade fixing things?

Jim

Jim Brandt
Administrative Computing Services
University at Buffalo

10

I installed the 3.6.1 upgrade with great anticipation, fired up the
server, logged in, clicked on a link…and logged in again.

For me, looks like multiple logins are still not squashed. Details:

Mac OS X 10.4 server
perl 5.8.6
apache
Oracle 9i
using LDAP integration

Install history:

  • had 3.4.5
  • upgraded to 3.6.0
  • upgraded to 3.6.1rc2 #Thought maybe that would fix the login
  • upgraded to 3.6.1

I’ve had this problem ever since April starting with RT 3.4.5. The
problem occurs with FCGI, Apache 2.0.54, 2.0.55, 2.0.58, 2.0.59, MySQL
4.1, 5.0, DBD-mysql 2.9007, 3.0004, Perl 5.8.7, 5.8.8 and persists with
RT 3.6.0.

I have just (finally!) fixed it on Gentoo by upgrading Apache-Session to
dev-perl/Apache-Session-1.80-r1 (it was at dev-perl/Apache-Session-1.80)

I’m still using 3.6.0

Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

11

dev-perl/Apache-Session-1.80-r1 did n’t work for me …
I had rt-3.6.0 installed for few weeks without any of the logout problems, few days ago we upgraded the system/perl modules and suddenly this problem appeared … with every page, So I upgraded to 3.6.1 as suggested by Jesse as a fix, the problem was still there, I upgraded apache-session to 1.80-r1 as suggested by Chris and its still there …
Is there anything else need changing/upgrading to get rid of this ??
Also does anyone know what changes there are between 3.6.0 and 3.6.1 (in html and modules) ??
The system is Gentoo, apache 2.0.59 , mysql 5.0.24, DBD::mysql v3.0006, Perl v5.8.8, mod_perl v2.000002;, RT-3.6.1

Roy

Covington, Chris wrote:> On Wed, Aug 09, 2006 at 10:51:43AM -0400, Jim Brandt wrote:

I installed the 3.6.1 upgrade with great anticipation, fired up the
server, logged in, clicked on a link…and logged in again.

For me, looks like multiple logins are still not squashed. Details:

Mac OS X 10.4 server
perl 5.8.6
apache
Oracle 9i
using LDAP integration

Install history:

  • had 3.4.5
  • upgraded to 3.6.0
  • upgraded to 3.6.1rc2 #Thought maybe that would fix the login
  • upgraded to 3.6.1

I’ve had this problem ever since April starting with RT 3.4.5. The
problem occurs with FCGI, Apache 2.0.54, 2.0.55, 2.0.58, 2.0.59, MySQL
4.1, 5.0, DBD-mysql 2.9007, 3.0004, Perl 5.8.7, 5.8.8 and persists with
RT 3.6.0.

I have just (finally!) fixed it on Gentoo by upgrading Apache-Session to
dev-perl/Apache-Session-1.80-r1 (it was at dev-perl/Apache-Session-1.80)

I’m still using 3.6.0

Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

The rt-users Archives

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

12

At Monday 8/14/2006 09:33 AM, Roy El-Hames wrote:

dev-perl/Apache-Session-1.80-r1 did n’t work for me …
I had rt-3.6.0 installed for few weeks without any of the logout
problems, few days ago we upgraded the system/perl modules and
suddenly this problem appeared … with every page, So I upgraded to
3.6.1 as suggested by Jesse as a fix, the problem was still there, I
upgraded apache-session to 1.80-r1 as suggested by Chris and its still there …
Is there anything else need changing/upgrading to get rid of this ??
Also does anyone know what changes there are between 3.6.0 and 3.6.1
(in html and modules) ??
The system is Gentoo, apache 2.0.59 , mysql 5.0.24, DBD::mysql
v3.0006, Perl v5.8.8, mod_perl v2.000002;, RT-3.6.1

Roy

Roy,

I can’t answer your question, but I’m curious to ask another question
to all the people who have this problem - do you have a CNAME/alias
for your RT host? We do - the published URL for our RT system uses
the CNAME. I’ve found that using the actual hostname or its IP
address to access RT eliminates the problem. I have no idea why, but
I’d like to see if others see the same behavior.

Steve

13

dev-perl/Apache-Session-1.80-r1 did n’t work for me …
I had rt-3.6.0 installed for few weeks without any of the logout problems,
few days ago we upgraded the system/perl modules and suddenly this problem
appeared … with every page, So I upgraded to 3.6.1 as suggested by Jesse
as a fix, the problem was still there, I upgraded apache-session to 1.80-r1
as suggested by Chris and its still there …
Is there anything else need changing/upgrading to get rid of this ??
Also does anyone know what changes there are between 3.6.0 and 3.6.1 (in
html and modules) ??
The system is Gentoo, apache 2.0.59 , mysql 5.0.24, DBD::mysql v3.0006,
Perl v5.8.8, mod_perl v2.000002;, RT-3.6.1

Roy,

Try using the stable version of DBD-mysql. I am using 2.9007

ps - FastCGI is faster than mod_perl

Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

14

Thanks Steve and Chris, but I tried both suggestions (cname changed to
hostname and down grading to DBD::mysql 2.9007) neither worked …
I got rid of the relogin by changing the data type for a_sesison;
ALTER TABLE sessions CHANGE a_session a_session LONGBLOB;
which is not ideal ??
did anyone who had this problem before managed to get it fixed using 3.6.1??
I look forward to any suggestions by anyone?

Roy

Covington, Chris wrote:> On Mon, Aug 14, 2006 at 02:33:45PM +0100, Roy El-Hames wrote:

dev-perl/Apache-Session-1.80-r1 did n’t work for me …
I had rt-3.6.0 installed for few weeks without any of the logout problems,
few days ago we upgraded the system/perl modules and suddenly this problem
appeared … with every page, So I upgraded to 3.6.1 as suggested by Jesse
as a fix, the problem was still there, I upgraded apache-session to 1.80-r1
as suggested by Chris and its still there …
Is there anything else need changing/upgrading to get rid of this ??
Also does anyone know what changes there are between 3.6.0 and 3.6.1 (in
html and modules) ??
The system is Gentoo, apache 2.0.59 , mysql 5.0.24, DBD::mysql v3.0006,
Perl v5.8.8, mod_perl v2.000002;, RT-3.6.1

Roy,

Try using the stable version of DBD-mysql. I am using 2.9007

ps - FastCGI is faster than mod_perl

Chris Covington
IT
Plus One Health Management
75 Maiden Lane Suite 801
NY, NY 10038
646-312-6269
http://www.plusoneactive.com

The rt-users Archives

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

15

Stephen Turner wrote:

Roy,

I can’t answer your question, but I’m curious to ask another question to
all the people who have this problem - do you have a CNAME/alias for
your RT host? We do - the published URL for our RT system uses the
CNAME. I’ve found that using the actual hostname or its IP address to
access RT eliminates the problem. I have no idea why, but I’d like to
see if others see the same behavior.

Steve

Steve,

We have a CNAME for our RT server as well. I’ve tried accessing it with
the real machine name and with the IP. I also converted the apache
server to remove the CNAME as a virtual host and list only the actual
hostname. In all cases, I still saw the re-login issue in my testing.

It makes some sense that the problem could be related to the server name
since Jesse mentioned that the source has something to do with internal
redirects. I haven’t been able to narrow down the actual location of the
problem.

Jim

Jim Brandt
Administrative Computing Services
University at Buffalo

16

we use a cname with no ill effects.On Aug 14, 2006, at 10:38 AM, Stephen Turner wrote:

I can’t answer your question, but I’m curious to ask another
question to all the people who have this problem - do you have a
CNAME/alias for your RT host? We do - the published URL for our RT
system uses the CNAME. I’ve found that using the actual hostname or
its IP address to access RT eliminates the problem. I have no idea
why, but I’d like to see if others see the same behavior.

smime.p7s (2.47 KB)

17

I think I’ve found some extra information regarding the login problem,
at least while using Apache::Session::File on my (Mac OS X server, perl
5.8.6) system. After doing a bunch of debugging, I’ve found that
Apache::Session gets itself in a state where it can’t get a write lock
on the session file. Apache::Session doesn’t error check it’s flock
calls, so it happens silently.

I found this post on perlmonks that suggested manual calls to DESTROY
can help the problem:

http://perlmonks.org/?node_id=435977

so I put one near the end of autohandler.

However, when I did this, the server just hung. Looking into the
Apache::Session::lock::File code, I found that it’s trying to get an
exclusive lock and it’s blocking when trying to write. So I hacked it on
our dev system to just return when it can’t get the lock. After doing
that, my log has a bunch of these:

[warning]: Unable to get exclusive lock (Resource temporarily
unavailable). Moving along… at
/Library/Perl/5.8.6/Apache/Session/Lock/File.pm

I then added a call to release_all_locks, thinking it might help in the
final write to the session file.

After these hacks, I did get the multiple login issue to go away. But, I
still get several of the above warnings on the initial page load.

I don’t consider this a true fix since I’m not sure of the repercussions
of manually releasing the locks, but I think it demonstrates that part
of the problem is in Apache::Session::File (or the file system itself)
somewhere. The only information I could find to indicate what’s
happening is that something isn’t playing nice with the file locks. And
I can’t explain why it appears to resolve itself after a few logins. Is
there something special happening on the first login that triggers these
locking problems?

I’m sorry I can’t present a solution, but I hope this might help move
toward a fix or workaround.

Jim

Jim Brandt
Administrative Computing Services
University at Buffalo