0.10-stable throwing 500 Server Error

[trac@…]

I have my installation of Trac set to update against the 0.10-stable branch every night, and as of last night (midnight GMT) my installation of Trac is regularly throwing 500 Internal Server Errors. When I can get Trac to display properly, it displays without the CSS styling.

The error message in the Trac log file is the rather cryptic

2007-03-23 11:48:23,232 Trac[env] WARNING: Component <trac.env.EnvironmentSetup object at 0xb77c746c> requires environment upgrade

I'm current using [5116], and Trac displays its version at 0.10.4dev. I also have a number of plugins installed, downloaded from Trac-Hacks; none of these appear to be logging any information at a severity level above DEBUG, however.

[Christian Boos]

When I can get Trac to display properly, it displays without the CSS styling.

Well, it would help to actually read what is displayed: you need to upgrade your environment using the trac-admin $TRAC_ENV upgrade command.

We trigger an internal server error on purpose when we see that the environment needs to be upgraded.

[trac@…]

That command did help; many thanks. I've updated the cron job to include this command.

When Trac was displaying, it was displaying all the usual content, but without the CSS styling.

[Christian Boos]

When Trac was displaying, it was displaying all the usual content, but without the CSS styling.

Oh, sorry then for my harsh comment ;-) This is actually a bug, it should display the error message in a readable way.

[anonymous]

Replying to cboos:

Oh, sorry then for my harsh comment ;-)

No problem :)

This is actually a bug, it should display the error message in a readable way.

Hmmm, interesting. It was a mixture of both; generally it would present a 500 Internal Server Error, but if I refreshed the page sufficiently many times, Trac would eventually display its content, and I was still able to post comments, etc., in this manner. Maybe there should some kind of lock implemented to prevent this happening?

[Christian Boos]

The internal server error should now be displayed (r5119).

What you saw was due to a mix of versions: some requests were processed by processes running the old code (those which succeeded), some by processes running the new code (those which were failing).

Usually, the requirement for upgrading will make you stop the server, upgrade and then restart your server. If you don't do that but perform instead a "hot" upgrade, then you'll see the exact opposite: the requests served by the processes running the new code will now succeed and the old code will now fail (the error will be slightly different, something like "the database version is newer").

This is exactly the effect I was looking for, as allowing both code bases to run successfully in this case lead to even more subtle errors (the repository cache syncs made by the old code were confusing the new code).