Page MenuHomePhabricator

Disabling sessions in memcached produces open() error
Closed, ResolvedPublic

Description

Author: eugenekay

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


Version: 1.18.x
Severity: normal

Details

Reference
bz26360

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:24 PM
bzimport set Reference to bz26360.
bzimport added a subscriber: Unknown Object (MLST).

eugenekay wrote:

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.

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

eugenekay wrote:

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.

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.

Looks like my fault from bug 11613 / bug 11381 (r49370).

I hadn't touched it since my comment above taking blame :)

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