Topic on Project:Support desk/Flow

See Manual:Job queue#Changes introduced in MediaWiki 1.22 for current bugs and possible workarounds until this issue is fixed.

I installed fresh 1.22, no extensions, on two servers and it fails after 2-3 pages. I've tried about 10 different installs of different servers. Early versions of the 1.22alpha (wmf7?) worked great, but the new release of 1.22 slows down and then crashes after 1 page view.

The problem occurs immediately after creating the site: I click 'go to my wiki', then 'login', then type in my login clicking sign in button. This causes it to freeze and eventually my hosting company displays a picture of a bomb. :) Clicking around the site without loging in does the same.

I'm not a programmer but my installations of MediaWiki from 1.17-1.21 have run perfectly on the same configuration. I've tried it on two servers with different configurations. Same result 1.22+

PHP	5.3.28 (cgi-fcgi)
MySQL	5.5.32-31.0-log

The CPanel process display shows:

PID	Process	Virt MEM	MEM	Time Running	Kill
1014	runJobs.php --maxjobs 1	280360 kB	43316 kB	786 secs	Kill Process
3220	runJobs.php --maxjobs 1	258148 kB	19732 kB	726 secs	Kill Process
8645	runJobs.php --maxjobs 1	283576 kB	38100 kB	5221 secs	Kill Process
8649	runJobs.php --maxjobs 1	259172 kB	17420 kB	5221 secs

with the 5221 increasing with each refresh. Help!

Hi!

Can you say, if this is somehow related to https://bugzilla.wikimedia.org/show_bug.cgi?id=58719 ? In that issue the wiki still displays fine, but jobs are not executed just like they are not for you. Or are the jobs executed for you and they only do not shut down properly?

If you have shell access, you can try running the maintenance script runJobs.php from the shell. This will not solve your initial problem, but at least the current jobs should then all be done.

Another user has the same problem, in bug 47375. Backlinking from that bug to this post

Specifically, see comment #9 of bug 47375.

What versions of PHP and mySQL are on your problematic servers?

Well, the PHP and MySQL versions are already present in the first post of this thread, easily visible because they're in preformatted text :)

Thanks for the comments, I'd really like to get past this and install.

Here's what the install profiler says about my system. I use the default install options (binary, mySQL)

PHP 5.3.28 is installed.
Warning: Could not find APC, XCache or WinCache.
Object caching is not enabled.
Found ImageMagick: /usr/bin/convert.
Image thumbnailing will be enabled if you enable uploads.
Found the Git version control software: /usr/bin/git.
Using server name "
Using server URL 
Warning: Your default directory for uploads /home/website/public_html/234/images/ is vulnerable to arbitrary scripts execution.
Although MediaWiki checks all uploaded files for security threats, it is highly recommended to close this security vulnerability before enabling uploads.
Using the intl PECL extension for Unicode normalisation.
Warning: The installed version of the Unicode normalisation wrapper uses an older version of the ICU project's library.
You should upgrade if you are at all concerned about using Unicode.

A couple days later my processes look like this:

PID	Process	Virt MEM	MEM	Time Running	Kill
1014	runJobs.php --maxjobs 1	280360 kB	24052 kB	29670 secs	Kill Process
3220	runJobs.php --maxjobs 1	258148 kB	7232 kB	29670 secs	Kill Process
8645	runJobs.php --maxjobs 1	283576 kB	16316 kB	29670 secs	Kill Process
8649	runJobs.php --maxjobs 1	259172 kB	7780 kB	29670 secs	Kill Process
19069	cpaneld - serving 64.231.49.215	95900 kB	12316 kB	14 secs	
19172	cpaneld - serving 64.231.49.215	95696 kB	11720 kB	11 secs	
19173	cpaneld - serving 64.231.49.215	95508 kB	11476 kB	11 secs	
19174	cpaneld - serving 64.231.49.215	95696 kB	11908 kB	11 secs	
19175	cpaneld - serving 64.231.49.215	95828 kB	12084 kB	11 secs	
19176	cpaneld - serving 64.231.49.215	96096 kB	12340 kB	11 secs	
19569	cpanel - ./frontend/Crystal/sg_files/processes.php	122940 kB	43964 kB	0 secs	Kill Process
19587	cpanel - phpengine.1389580166.19569rzwKGoMVFv	136172 kB	9976 kB	0 secs

On a possibly unrelated note, I see strange characters --> អំពី beside the website name at the bottom of the pagewhen I install 1.22 or higher.

I have a similar problem. Since version 1.22 came out, all MediaWikis installs on my servers running cPanel hang when accessing the main page (right after install, no custom modifications done). Here is the list of processes when accessing the main page ONCE:

See Manual:Job queue#Changes introduced in MediaWiki 1.22 for possible workarounds until this is fixed.

Hi, I am experiencing this issue as well, I have an install of 1.19 that is working fine, but once I upgrade to 1.22 when I try to login it just hangs and never completes.

I am on a shared hosting service so I can't see the processes currently running but I am using PHP version 5.3.27 MySQL version 5.5.32-cll

The only strange occurrence I noticed on the main page before trying to login caused the server to hang is that my logo was no longer there. If there is anything else I can gather to help solve this issue please let me know.

More system information from my provider:

Linux Cent OS 6 operating system. We provide Apache server, MySQL Percona 5.5 version database engine, PHP with support of 7 different versions, up to 5.5.

I tried a few different PHP versions on my installs, and still the same problem occured.

Also, I noticed that the page view hit counter jumped by hundreds with each click immediately after install. I tried a few times on different installs.

Maybe there is an loop in the code? I got to over 1500 hits in a few seconds. It happened on two different servers so it I don't think I'm under any spam attack. Perhaps that's part of the massive slowdown that's happening.

I created a bug for the main issue of slowdown/crash here. https://bugzilla.wikimedia.org/show_bug.cgi?id=57671

Is there some ideal web provider I should be using instead?

Also, I noticed that the page view hit counter jumped by hundreds with each click immediately after install. I tried a few times on different installs.

Maybe there is an loop in the code? I got to over 1500 hits in a few seconds. It happened on two different servers so it I don't think I'm under any spam attack. Perhaps that's part of the massive slowdown that's happening.

I created a bug for the main issue of slowdown/crash here. https://bugzilla.wikimedia.org/show_bug.cgi?id=57671

Is there some ideal web provider I should be using instead?

I have 1.22 installed with no issues. That's really strange.

this commit mentions that If $wgPhpCli is not set to an actual path or safe mode is on, then the old code will be used.

You may try to set $wgPhpCli to an empty string ($wgPhpCli = "";) to use the old running job system until this issue is investigated an addressed.

Edit: Fixed code to empty $wgPhpCli.

I was also experiencing this issue in 1.22. Setting that to an empty string as you suggested fixes 1.22 for me.

However the line should be:

$wgPhpCli = "";

with the quote marks to be valid.

Thank you. This should allow me to upgrade my installation and have a temporary solution until the issue is fixed in a future release.

Setting $wgPhpCli = ""; is only a workaround, no fix. $wgPhpCli defaults to /usr/bin/php and it should not be necessary to change $wgPhpCli, if you have PHP available at that location. That $wgPhpCli needs to be changed in that case anyway is a bug, which should be fixed.

See here for the bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=58719

This workaround above appears to 'work', which is great! However the bug remains, even on the latest master snapshot.

Repository MediaWiki core Branch master HEAD 2dffe9485209a01984f0902903384f3559094f1f Date: Fri, 14 Feb 2014 01:08:45 +0000

To review, the server still crashes without the $wgPhpCli = ""; fix. I get a "504 Gateway Timeout" Interestingly, the "This page has been viewed ___ times" counter jumps by increments of 8 each time I click "Main Page" to refresh it. With $wgPhpCli = ""; added, it the goes up by 1, like a good install should. :)

Our experience is best shown visually. From Google Webmaster Tools Crawl Stats. We upgraded to MW 1.22.0 in Dec 2013, corresponding exactly to when the upward spike occurs. We changed $wgPhiCli to an empty string about a week ago, exactly when the return to "normal download times. Our wiki is hosted at Bluehost, who support multiple PHP versions and therefore our PHP is not at the default location.

The issue you describe seems to be bug 58719, which has been resolved, although I think it wasn't included in 1.22.2. It will definitively be included in 1.22.3.

The fix for #58719 definetely is not part of 1.22.2, but will only be available in 1.22.3. However, there have already been people in this very thread who say they have applied the patch but they experience the problem nonetheless.

I am really not sure, whether the patch fixes the issue.

I'm getting the same problem - core dumps with runjobs.php the culprit.

Would it help to send the core dumps to anybody?

Fustbariclation (talk)

Simply set $wgPhpCli = false; until the related bugs are fixed