Thread:Project:Support desk/No login page after 1.21.3 to 1.22 upgrade - Uncommitted DB writes?

I'm editing this post title to reflect new and substantially different information:

This problem occurs regardless of:

1. updating a 1.21.3 wiki using Installatron

2. updating a 1.21.3 wiki manually using code downloading direct from mediawiki

3. creating a brand new wiki with 1.22 in a new domain with no previous content

The new wiki behaves slightly differently than the updated wikis: the initial page takes a LONG time to load, and then after selecting the login link, it eventually 500s out.

I'm now wondering if anybody else has 1.22 working, fresh install or update to an existing wiki, on a similar configuration: apache 2.2.26, php 5.4.22, running suphp?? I'm aware of the general state of suphp support, but it's still popular and every CMS running on our servers is still working except mediawiki 1.22.

--- original post ---

This server (RHEL5) has mysql Ver 14.14 Distrib 5.1.70 and PHP 5.4.22. After upgrading from mediawiki 1.21.3 to 1.22, the main wiki page displays, but the login page (after clicking on "login") does not. This wiki requires a login to view.

These are the only messages appearing in the error log:

[13-Dec-2013 10:57:29 America/Chicago] PHP Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/.../wiki/includes/db/Database.php on line 3944

While searching for this error, we found a recent mention of setting $wgCommandLineMode = true to work around the problem, although we're not sure exactly where to do that, or if there is a pending fix for this in a future release.

This problem occurs for two completely separate wikis installed on two different servers (the other server is configured similarly but with RHEL6.)

Thanks for any suggestions.

Here is additional debugging info from when "login" is selected, with "testsite" replacing the actual url:

Start request GET /index.php?title=Special:UserLogin&returnto=Special%3ASpecialPages HTTP HEADERS: USER-AGENT: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:25.0) Gecko/20100101 Firefox/25.0 HOST: wiki.testsite.net CONNECTION: keep-alive ACCEPT-LANGUAGE: en-US,en;q=0.5 REFERER: http://wiki.testsite.net//index.php?title=Special:SpecialPages ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 ACCEPT-ENCODING: gzip, deflate COOKIE: __utma=132645968.1105903451.1371837585.1377636307.1384794043.4; __utmz=132645968.1371837585.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) CACHES: EmptyBagOStuff[main] SqlBagOStuff[message] SqlBagOStuff[parser] LocalisationCache: using store LCStore_DB Fully initialised IP: 10.10.241.165 Connected to database 0 at localhost [cookie] session_set_cookie_params: "0", "/", "", "", "1" wfFixSessionID: PHP's built in entropy is disabled or not sufficient, overriding session id generation using our cryptrand source. MWCryptRand::realGenerate: Generating cryptographic random bytes for wfFixSessionID/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate MWCryptRand::realGenerate: mcrypt_create_iv generated 16 bytes of randomness. MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer. Unstubbing $wgAuth on call of $wgAuth::validDomain from LoginForm::load Connected to database 0 at localhost MessageCache::load: Loading en... got from global cache Unstubbing $wgParser on call of $wgParser::firstCallInit from MessageCache::getParser Parser: using preprocessor: Preprocessor_DOM Unstubbing $wgLang on call of $wgLang::_unstub from ParserOptions::__construct MWCryptRand::realGenerate: Generating cryptographic random bytes for LoginForm::setLoginToken/MWCryptRand::generateHex/MWCryptRand::realGenerateHex/MWCryptRand::generate/MWCryptRand::realGenerate MWCryptRand::realGenerate: mcrypt_create_iv generated 16 bytes of randomness. MWCryptRand::realGenerate: 0 bytes of randomness leftover in the buffer. DatabaseBase::query: Writes done: INSERT IGNORE INTO `mw_msg_resource` (mr_lang,mr_resource,mr_blob,mr_timestamp) VALUES ('en','user.options','{}','20131213193735')

Approximately accompanied by:

The installation also produces a huge number of processes running

maintenance/runJobs.php --maxjobs 1

We can load a fresh install of 1.22, connect it to the existing mysql db, and upgrade the mysql db to 1.22 using the command line script. At that point the login page is broken however. When we then revert the code (but not the db) to 1.21.3, the login page works again (with the 1.22 db updates intact.)