Strange errors after upgrade

Hello all.

I recently upgraded an RT installation from 3.1.10 to 3.2.2, and the
web interface seems to be incredibly touchy now. Most page loads
require me to hit reload a couple of times before I actually get
content; I have to hit the “Login” button at least two or three
times before I actually get logged in, and occasionally when working
with tickets, I get some crazy Perl error which claims to be
about /opt/rt3/var/session_data not being writeable (which was changed
to 0777 just to be sure a little while ago when I first noticed these
problems), but whose traceback seems to indicate some kind of weird
DBI problem.

When I get this error, the RT vhost becomes completely unresponsive,
and I have to bounce Apache to have anything work on it. I’ve attached
the error to this message.

The RT installation is getting its data from a MySQL 4 database, and
when I did the upgrade, it actually moved to a different box as well,
so there’s no lingering RT code from a previous release to get in
the way. The old box that 3.1.10 used to be on was a single-processor
box, and the new one is SMP (and the CPUs are a little bit slower than
the single-processor it had been on before), and since all of these
errors that I’m getting aren’t really repeatable every time, I’m
inclined to think that perhaps it’s a problem with the box being SMP.

The box RT’s been moved to serves up a bunch of other content too,
all of which is working fine, so I don’t think it’s a problem with
the actual box hardware. Also, the mailgate stuff seems to work fine;
I haven’t experienced any problems with that yet.

Thanks for any ideas!

-CJ

WOW: Kakistocracy | “The ships hung in the sky in much the same
apocalyptech.com/wow | way that bricks don’t.” - Douglas Adams,
rt@apocalyptech.com | The Hitchhiker’s Guide To The Galaxy

rt-error.txt (4.69 KB)

I recently upgraded an RT installation from 3.1.10 to 3.2.2, and the
web interface seems to be incredibly touchy now.

I think some others have mentioned having to clear the var/mason_data
directory after upgrades and restart apache to make things work. I’ve
never been quite sure what was safe to remove so I rename the existing
directory and create a new one with the same owner/permissions, but I
don’t think I’ve ever had to put any of the old stuff back.

Les Mikesell
les@futuresource.com

Les Mikesell wrote:

I think some others have mentioned having to clear the var/mason_data
directory after upgrades and restart apache to make things work. I’ve
never been quite sure what was safe to remove so I rename the existing
directory and create a new one with the same owner/permissions, but I
don’t think I’ve ever had to put any of the old stuff back.

I’ll give that a shot, though as I mentioned, this was an “upgrade” but
but it was a clean install onto a new box (had just copied database
data over to the new box), so there shouldn’t have been anything
conflicting in there.

I did manage to find a mention of a similar problem on the list
archives finally, and they recommended a DBI/DBD-mysql recompile, so
I did that and we’ll see if that fixes anything. Dunno how the
stuff on that box could have gotten out of sync, as I’m pretty sure
there’s other stuff using it, but it won’t hurt to recompile it,
anyway…

-CJ

WOW: Kakistocracy | “The ships hung in the sky in much the same
apocalyptech.com/wow | way that bricks don’t.” - Douglas Adams,
rt@apocalyptech.com | The Hitchhiker’s Guide To The Galaxy