Last modified: 2011-07-16 18:02:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28360, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26360 - Disabling sessions in memcached produces open() error
Disabling sessions in memcached produces open() error
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-18 06:49 UTC by EugeneKay
Modified: 2011-07-16 18:02 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description EugeneKay 2010-12-18 06:49:56 UTC
Using the Installer script, configuring a Memcached server results in a broken install. $wgMemCachedServers is configured as such by the installer:

$wgMemCachedServers = array( 0 => "127.0.0.1:11211" );

The documentation, however, specifies that the syntax for a single Memcached server should be:

$wgMemCachedServers = array( "127.0.0.1:11211" );

The first configuration results in an error, as such:

Warning: Unknown: open(tcp://127.0.0.1:11211/sess_(redacted), O_RDWR) failed: No such file or directory (2) in Unknown on line 0

Changing the value to the second(documented) syntax solves the issue. I am unsure of why this matters to PHP, as my understanding of the array() function says that both should produce an equivalent PHP array, but I have not looked further into this behavior.
Comment 1 EugeneKay 2010-12-18 07:26:37 UTC
After looking at it closer, it seems I was barking up the wrong tree.

Both syntaxes above work, the problem variable is in fact $wgSessionsInMemcached. It is listed as being optional in the documentation, and is not set by the installer. However, leaving it disabled leads to the Warning listed above. The installer should be made to set $wgSessionsInMemcached=true; by default, or the variable eliminated entirely(and the code for Session storage location reworked).

That decision is a bit above my pay grade, methinks.
Comment 2 Roan Kattouw 2010-12-21 00:39:14 UTC
(In reply to comment #1)
> The installer should be made to set
> $wgSessionsInMemcached=true; by default,
No it shouldn't, because most people don't want sessions in memcached.

> or the variable eliminated
> entirely(and the code for Session storage location reworked).
> 
Nor that, because we want people to be able to put their sessions someplace other than memcached.

It's also very strange that /disabling/ sessions in memcached should result in the warning you mention; it looks like that's what you'd get after /enabling/ it.
Comment 3 EugeneKay 2010-12-21 00:43:26 UTC
I think this is because $wgMainCacheType is set to CACHE_MEMCACHED, so session data is attempted to be stored there, but with $wgSessionsInMemcached set to false, it is prevented from doing so.

Why this produces a Warning from open(), I haven't a clue.
Comment 4 Brion Vibber 2010-12-27 02:03:48 UTC
It kind of looks to me like this error might be coming from PHP's memcached module's session handler, not from MediaWiki's:

http://www.php.net/manual/en/memcached.sessions.php

When using the session handler provided by PHP's memcached module, you basically set a few settings in your php.ini:

session.handler = memcache
session.save_path = tcp://127.0.0.1:11211


With $wgSessionsInMemcached *enabled*, MediaWiki takes over the session handler settings completely, overriding whatever's configured. But with it *disabled* (as default), MediaWiki will override session.save_handler to whatever's set in $wgSessionHandler unless it's null.

By default, $wgSessionHandler is set to "files" -- which is normally the default session handler on most PHP setups.

As a result, MediaWiki is changing your session settings *FROM* the PHP memcached module *TO* files, which gets very confused with a session path that's set to "tcp://blah". :)

Really we probably should *not* be messing with the session handler settings unless we're taking them over entirely. I think we initialized it to files back in the day because there were a lot of bizarrely broken shared hosting systems out there that basically just had totally broken session stuff, but that might have just been a voodoo fix.

There are probably a few other old bug reports on the subject of the session handlers being overridden.
Comment 5 Chad H. 2010-12-27 13:46:02 UTC
Looks like my fault from bug 11613 / bug 11381 (r49370).
Comment 6 Mark A. Hershberger 2011-01-29 14:17:23 UTC
Chad, is this fixed now?
Comment 7 Chad H. 2011-01-29 15:50:30 UTC
I hadn't touched it since my comment above taking blame :)
Comment 8 Brion Vibber 2011-07-16 18:02:43 UTC
Chad's r92124 should resolve this for trunk/1.19, so going ahead and closing as fixed.

Note that r49370 didn't actually cause the issue; it just maintained the same behavior we previously had as the default case, while allowing it to be overridden.

Changing the behavior to leave the site's existing PHP config as-is by default does seem like the right thing, and I don't think we had a _really_ good reason for overriding it in the first place (IIRC there were originally reports of things getting left with another app's 'user' setting in place or something, which is probably super-obsolete).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links