Topic on Project:Support desk

In MediaWiki 1.27 sessions are no longer stored using the default php session storage, but on the object cache. If you've changed $wgMainCacheType, you may need to tune $wgSessionCacheType, in case the caching you've chosen is not persisting data across requests. Setting $wgSessionCacheType = CACHE_DB; would be a sensible value.

Hello,

I installed MediaWiki 1.27.0 on Debian Jessie with PHP 5.6.22 last week and finally got around to start editing it. However, the account I've created gets a login failure, namely: "There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."

The PHP session directory exists and should be writable by the PHP process and webserver from what I can see. (I found this discussion Topic:Pjby0sdeg3e60rfy which isn't very edifying, and also six years old, but it's still the least bad source of possible solutions I could find -- everything else is about as old and has less useful information).

Let me know if you need any more information, and I'll do my best to provide it.

Apparently a problem with MediaWiki v1.27. Check this out: Topic:T75cloz7981b8i92.

Yep, changing $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING seems to have solved it. Thanks a lot!

This worked for me, had to edit the LocalSettings.php with the change $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING seems to have solved it for me as well.

I had a 1.27-release running for over a month without problems and should upgrade the production-environment today from 1.23 to 1.27 and encountered the same error on our testenvironment now. Patched to 1.27.1 a few days ago and it was still running fine then. Weird. Can't figure it out. Restored a backup from production and did the upgrade again to 1.27.0 and still the same error. Suggested solutions don't work. How to solve this? Now again back to 1.23.14.

The wiki causing trouble was readonly through $wgReadOnly. After uncommenting this line it now seems to be working again. Another test wiki on 1.27 was still running fine. If I use $wgReadOnly there it complains about a database being locked.

But as I have $wgGroupPermissions on this readonly wiki set to false for editing it's still a readonly-wiki.

Hi All - recently upgraded to Ubuntu 4.4.0-34 which made me work a bit on getting Apache set up right as during the upgrade the php configuration didn't turn out. So on php7. Once I got that going, I went through the command line upgrade of mediawiki to 1.27 but there were several php modules missing from apache2 so got these installed. Once got this all sorted out I got stumped on this same issue. As you mentioned here setting to CACHE_ANYTHING also worked for me. Just documenting this so if others that do a major OS upgrade they may find this helpful. This article did the trick for me!

Hi

I have the same error:

OS: Ubuntu 14.04.5

PHP: 5.5.9-1ubuntu4.20

Apache: 2.4.7-1ubuntu4.13

MediaWiki: 1.27.0 (not upgraded)

I have tried setting wgMainCacheType from CACHE_ACCEL (the default) to CACHE_EVERYTHING, CACHE_NONE or CACHE_DB but it dowsn't work.

I also tried setting wgSessionCacheType from CACHE_ANYTHING (the default) to CACHE_DB but still no success.

Do you have any other ideas?

I installed a fresh 1.26.4 and migrated the content (dumpBackup.php) now it works again (CACHE_ACCEL is the default in 1.26.4). Im still interested in why it failed in 1.27.x so if somebody gives me debug instructions i am willing to help.

If you want, you can follow the related phabricator task here.

Is there a way to change CACHE_ACCEL?

Still exists in 1.28.0 with up to date Ubuntu Server (16.04), Updated php from the repos, and everything. Changing $wgMainCacheType from CACHE_ACCEL to CACHE_ANYTHING as suggested above in LocalSettings.php appears to be the fix.

Yup, still in 1.28.

Fixed with $wgSessionCacheType = CACHE_DB;

Which means you can leave $wgMainCacheType = CACHE_ACCEL; where it is.

Same issue with 1.28.2 if $wgReadOnly is set. When I comment that out it works, but this is for a replicated site and MySQL Master-Slave replication is then broke when mediawiki writes to db. Also making MySQL DB read-only renders same results.

Bugreport that on Phabricator.

$wgMessageCacheType = $wgParserCacheType = $wgMainCacheType ;

$wgSessionCacheType = CACHE_ANYTHING;

$wgMainCacheType = CACHE_MEMCACHED;

$wgMemCachedServers = [ '127.0.0.1:11211' ];

seems to do the job, Great

Don't configure Memcached variables unless you have Memcached installed and running

You two above should not reply to a 5 years old comment that was already solved (Per IP user's comment).

Is there a way to lock threads like these to avoid necroposting in the future?