Jump to content

Topic on Project:Support desk

Errors after update from 1.21.3 or fresh install of 1.22

Pbt~mediawikiwiki (talkcontribs)

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
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
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
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:

[Fri Dec 13 13:47:34 2013] [error] [client] Script timed out before returning headers: index.php, referer: http://wiki.testsite.net//index.php?title=Special:SpecialPages

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.)

This post was posted by Pbt~mediawikiwiki, but signed as Pbt. (talkcontribs)


This is a known problem, I see that as well. A workaround might be to change PHPs error reporting to no longer show notices; this does not in any way fix the cause of the problem, but it only hides the symptoms. I think that this currently is the best solution.

This seems similar to https://bugzilla.wikimedia.org/show_bug.cgi?id=56269, which is visible after https://gerrit.wikimedia.org/r/#/c/79852/, but was already there before. Reason is that transactions in MediaWiki are broken.

As a workaround I have set $wgCommandLineMode = true;, however: I did that in a kind of maintenance script. This script is not executed each time a wiki page is called. You could set that by adding this line to LocalSettings.php, however, as the manual says: "Don't do it."

I personally also do not know, what else setting this variable changes and I think Manual:$wgCommandLineMode should really be extended with according information!

Pbt~mediawikiwiki (talkcontribs)

Thanks for the reply. We have php set to only log errors, not display them to users, if that's what you mean. The main wiki page loads and displays in the browser ("you must login in to view this wiki", etc.), but when the login link is clicked, nothing happens (except the errors are logged.) So there's no opportunity to attempt a login. Everything still works in the pre-upgrade wiki (we cloned it before attempting the upgrade.)

It's not clear if that uncommitted issue is definitely the cause of the login page not appearing, but it's the only entry in the error log, and doesn't appear in the 1.21.3 error log.

This post was posted by Pbt~mediawikiwiki, but signed as Pbt. (talkcontribs)

The message, which you posted only is a notice; basically the system should also run correctly with it. I think that the login page does not show up at all(!), is not caused by that one.

See blank page for some steps and ideas on how to debug that!

Pbt~mediawikiwiki (talkcontribs)

It did seem more like a warning vs. error, but that was still the only message after enabling the error display to the browser (as instructed in that link.) In the past (many versions ago) we've experienced the blank page problem, but it was always an out-of-memory error, and now we have a 512MB limit (confirmed with phpinfo().)

This post was posted by Pbt~mediawikiwiki, but signed as Pbt. (talkcontribs)

The "Uncommitted transaction" problem only is a PHP notice. As far as I can tell, a notice should not be able to produce a blank screen. When you see a blank screen, or - as you added above - a server error 500, then something else must be the cause.

Check the server error log to get information about the server error 500!

Pbt~mediawikiwiki (talkcontribs) (talkcontribs)

Hello, I don't know if it's related but I encounter PHP Notice: Uncommitted DB writes error when trying to update database for Semantic Mediawiki (the Mediawiki is new, version 1.22, and semantic mediawiki also). Database upgrade (Postgresql 9.3) won't work at all with original files. If I disable index creation in database upgrade file (SMW_SQLStore3_SetupHandlers.php), the upgrade process will look like completed but ends with such php notice and tables are not created... Many thanks if clear database access may be recovered with actual table creation, in my particular case (and others...). Sorry for being anonymous, I didn't create an account...

Bawolff (talkcontribs)

Probably not related. The DB error message can be caused by a lot of things.

Gogy82 (talkcontribs)


I just installed fresh copy of Wiki for the first time and I get the same error. I tried to login but it loads long time and nothing happened, just loading. I have longer timeout set in PHP config, but this should not be a problem to login.

Any ideas how to use fresh installation of Wiki?

I will use it for private stuff if that helps.

Best regards Gogy

Ciencia Al Poder (talkcontribs)

This may be related to problems with the new handling of the Job queue on page requests. Try setting $wgJobRunRate = 0; to see if problem disappears. You may need to set $wgPhpCli to false to revert to the old handling system that doesn't have this problem, until it's fixed.

Gogy82 (talkcontribs)

With JobRunRate set to 0 I was able to login. Notice exists but this is not what I care much in this moment, maybe later in new release, but I hope this will be solved later and upgrade should be made to handle this.

Ciencia, thank you very much for your answer and your time!

Ciencia Al Poder (talkcontribs)

For the notice, you should disable error reporting for E_NOTICE. For example:

// Report simple running errors
error_reporting(E_ERROR | E_WARNING | E_PARSE);

Note that having $wgJobRunRate = 0; cause jobs to not being run, so you must manually run runJobs.php periodically to run them, needed to refresh links, etc.

Hollosch (talkcontribs)

I've problems after update to 1.22.2 with PHP Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/.../wiki/includes/db/Database.php on line 3944

Is there a solution for this ?

Ebasso (talkcontribs)

Solved !!!

First i enabled SQL debug. Add in LocalSettings.php the following parameters:

$wgShowSQLErrors = true;

$wgDebugDumpSql = true;

$wgShowDBErrorBacktrace = true;

The error message show that the column iw_wikiid dont exist on table interwiki.

After I found the following patch <WIKI>/maintenance/archives/patch-iw_api_and_wikiid.sql

ALTER TABLE /*_*/interwiki
       ADD iw_wikiid varchar(64) NOT NULL;

after i created this column, all works fine!

P.S.: remember to remove the debug parameters

Ciencia Al Poder (talkcontribs)

This should not happen if you properly upgrade your MediaWiki installation, as explained in Manual:Upgrading. Specially, the part that talks about Run the update script

Collabet (talkcontribs)

Not solved! Running .../maintenance/archives/patch-iw_api_and_wikiid.sql => #1060 - Duplicate column name 'iw_api'.

Happens on a fresh installation of 1.22.2 + semantic bundle; cant create/move categories without getting the error.

Do I have to run the update script after installing latest downloads?!?

Ebasso (talkcontribs)

enable SQL Debug. This is the best option to check in your environmnent.

In my case the problem was in table interwiki, that already have column name 'iw_api', but did not have column 'iw_wikiid'.

Collabet (talkcontribs)

These lines are added to LocalSettings.php:

$wgShowSQLErrors = true;
$wgDebugDumpSql = true;
$wgShowDBErrorBacktrace = true;

But all I get is:

Notice: Uncommitted DB writes (transaction from DatabaseBase::query (LCStore_DB::get)). in /home/[...]/html/includes/db/Database.php on line 3944

Where do I check for more hints or where's some error-log for the notice?

Setting $wgJobRunRate to 0 or 0.01 did not change anything.

This bug keeps me from using my MW at all.

MarkAHershberger (talkcontribs)

First, add

 error_reporting( -1 );
 ini_set( 'display_errors', 1 );

to your LocalSettings.php file and see if any errors are displayed. If none are, try enabling debugging and see if the file shows you anything.

Collabet (talkcontribs)

Thx alot, these 2 lines helped to get more output - more than I can digest.

  • Funktion: SMW::executeHierarchyQuery
  • Fehler: 1044 Access denied for user 'USER289985'@'%' to database 'db_289985_1' (mysql.lima-city.de)

Followed by 29 lines of backtrace.

Dead end for my level of knowledge. So far, I really liked SMW, more than any of its derivates, but it seems useless without IT degree.

MarkAHershberger (talkcontribs)

The important bit there is this "Access denied for user ...". It looks like your permissions aren't set correctly for that user. Could you show the error to whoever hosts your site and see if they can help? (talkcontribs)

I also encountered the same problem, google-chrome-stable-33.0.1750.146-1.x86_64 can not log in, firefox, opera is no problem, the problem is chrome, or mediawiki problem? mediawiki-1.22.3.tar.gz

Ciencia Al Poder (talkcontribs)

A database error of "Access denied for user ..." is independent of the browser you're using. If that's not the same error, please open a new thread detailing what error message you get and doing what actions.

Reply to "Errors after update from 1.21.3 or fresh install of 1.22"