Topic on Project:Support desk

Hi all, this is my first post here, so please forgive me if I somehow break the webiquette of this site.

Affected wiki is a very small installation (roughly 100 pages only) with very few users. The URL can't be postet, it's a private website with password protection and delicate information. I don't have shell access to the web-server.

The environment is as follows:

• MediaWiki 1.23.2
• PHP 5.4.26-nmm1 (apache2handler)
• MySQL 5.5.35-nmm2-log
• Semantic MediaWiki 2.0
• $wgEnableParserCache and $wgCachePages are both set to false (for other reasons).

The problem came up after upgrading from MediaWiki 1.22 to the current version and upgrading Semantic MediaWiki as well. When the usual repair and cleanup-jobs of semantic MW are to be run, nothing happened. I had a look at the list of "open jobs", it showed over 100 jobs in the queue. Regardless of the value of $wgJobRunRate, nothing changed after accessing the Wiki a lot.

Is this a known issue? Searching the web didn't reveal any helpful information to me.

I'd appreciate any hints what I could do the get this Wiki to execute the jobs. Thank you in advance for your help!

Best regards,

Tobias

You can have more information reading Manual:Job queue.

Try running jobs directly with runJobs.php. If they're run successfully and there are no remaining jobs, then monitor the job queue for a day for example, and see if jobs get stuck there. If yes, then you might try to set $wgRunJobsAsync to false and see if that makes jobs being run again on page requests. If so, you might want to enable debugging while restoring that setting and let us know of any error you might encounter on the log.

Thank you for your reply! Since I don't have shell access to the web-server, running jobs directly with runJobs.php is some kind of a challenge. Using the "Maintenance"-extension, I managed to run the jobs. Afterwards, new jobs appeared on the queue and were not run on page requests, just like before.

As suggested, I set $wgRunJobsAsync to false, with success, the queue was processed. Before and after restoring the setting to default, I couldn't identify any error on the log though. Anything in particular to look for? Any suggestions?

Would you recommend to set $wgRunJobsAsync to false again and leave it that way or will this cause any other problems?

Thank you for your help!

In MediaWiki 1.22 and 1.23, the running jobs on page requests was modified, and the variable $wgRunJobsAsync was added just to revert to the old way of running jobs, as a fallback in case something goes wrong with this new development, as it seems to be your case. But still, none of the developers (including me) seem to be able to track down what's the problem with this new system, so debugging it will be useful to fix it on new releases.

If you want to help, follow those steps, when there are jobs in the job table:

Set this in LocalSettings.php:

$wgJobRunRate = 1;
$wgRunJobsAsync = true; // Or just comment out the line where you set it to false
$wgDebugLogFile = "{$wgUploadDirectory}/debug-{$wgDBname}.log"; // Set it to a directory writable by the webserver

Reload any page from your browser, best if you do that while not logged in, for example, in a "private browsing" tab, so you don't have to remove cookie information from the debug log.

After ensuring the debug log file has been created, restore LocalSettings to the previous state (removing the lines added for this test).

Look at the debug log and see if there's any error condition or something strange there. Ideally, it should contain debug for 2 requests: The first one, the page you reloaded first. The second one would be an internal request to SpecialRunJobs.php that would execute a small batch of jobs. You can post the relevant information here, or post it to (and post a link to it here) after redacting any private information (cookies, or maybe sensible paths). See Manual:How to debug#Logging for more info.

Also, delete the debug log once you're done.