Page MenuHomePhabricator

PHP Deprecated: Use of $_SESSION was deprecated in MediaWiki 1.27. [Called from session_write_close in (internal function)]
Closed, ResolvedPublicPRODUCTION ERROR

Description

Error
labels.normalized_message
[{reqId}] {exception_url}   PHP Deprecated: Use of $_SESSION was deprecated in MediaWiki 1.27. [Called from session_write_close in (internal function)]
FrameLocationCall
from/srv/mediawiki/php-1.44.0-wmf.28/includes/debug/MWDebug.php(386)
#0[internal function]MediaWiki\Exception\MWExceptionHandler::handleError(int, string, string, int)
#1/srv/mediawiki/php-1.44.0-wmf.28/includes/debug/MWDebug.php(386)trigger_error(string, int)
#2/srv/mediawiki/php-1.44.0-wmf.28/includes/debug/MWDebug.php(357)MediaWiki\Debug\MWDebug::sendRawDeprecated(string, bool, string)
#3/srv/mediawiki/php-1.44.0-wmf.28/includes/debug/MWDebug.php(238)MediaWiki\Debug\MWDebug::deprecatedMsg(string, string, string, int)
#4/srv/mediawiki/php-1.44.0-wmf.28/includes/GlobalFunctions.php(782)MediaWiki\Debug\MWDebug::deprecated(string, string, string, int)
#5/srv/mediawiki/php-1.44.0-wmf.28/includes/session/PHPSessionHandler.php(327)wfDeprecated(string, string)
#6[internal function]MediaWiki\Session\PHPSessionHandler->write(string, string)
#7/srv/mediawiki/php-1.44.0-wmf.28/includes/session/SessionManager.php(474)session_write_close()
#8[internal function]MediaWiki\Session\SessionManager->shutdown()
#9{main}
Notes

I see 2662 in production, all since 1.44.0-wmf.28 (T386223).

Details

Request URL
https://pl.wikipedia.org/w/api.php?action=query&format=*&formatversion=*&meta=*&notfilter=*&notformat=*&notlimit=*&notwikis=*
Related Changes in Gerrit:

Event Timeline

(Apparently from this morning's backport window.)

errors

I think it's bogus, PHPSessionHandler gets confused when the session is dirty on shutdown. The order of things is probably wrong in SessionManager::shutdown().

Can be reverted if the noise is a problem. Otherwise, I'll think about how to prove/disprove with a SessionManager change that this is an incorrect warning.

This is now the loudest log in prod. Would it make sense to revert of should we wait for a proper fix?

image.png (904×601 px, 80 KB)

Also triggered by one of the integration tests:

1) MediaWiki\Tests\Session\SessionBackendTest::testResetIdOfGlobalSession
Use of $_SESSION was deprecated in MediaWiki 1.27. [Called from session_write_close in (internal function)]

/vagrant/mediawiki/includes/debug/MWDebug.php:386
/vagrant/mediawiki/includes/debug/MWDebug.php:357
/vagrant/mediawiki/includes/debug/MWDebug.php:238
/vagrant/mediawiki/includes/GlobalFunctions.php:782
/vagrant/mediawiki/includes/session/PHPSessionHandler.php:327
/vagrant/mediawiki/includes/session/SessionBackend.php:280
/vagrant/mediawiki/tests/phpunit/includes/session/SessionBackendTest.php:957

Hello! I'm on train duty this week and this is still the number one error being logged.

errors

I think it's bogus, PHPSessionHandler gets confused when the session is dirty on shutdown. The order of things is probably wrong in SessionManager::shutdown().

Can be reverted if the noise is a problem. Otherwise, I'll think about how to prove/disprove with a SessionManager change that this is an incorrect warning.

Do you have the data you need for T362324? Is this still safe to revert? If so, could you revert?

We're still getting about 15 of these warnings a minute on the mediawiki-errors dashboard.

If you've got the data you need for T362324: Disable PHPSessionHandler in Wikimedia production, then removing this message would remove mental overhead for folks assigned to the train each week (as evidenced by all the train conductors commenting here ;))

We haven't found the time to investigate, but we're probably not going to learn anything new by logging these warnings forever. I think it'd be fine to switch them off.

Change #1155303 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[operations/mediawiki-config@master] Stop logging $wgPHPSessionHandling warnings for now

https://gerrit.wikimedia.org/r/1155303

Change #1155303 merged by jenkins-bot:

[operations/mediawiki-config@master] Stop logging $wgPHPSessionHandling warnings for now

https://gerrit.wikimedia.org/r/1155303

Mentioned in SAL (#wikimedia-operations) [2025-06-11T13:56:58Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1155299|Set $wgPHPSessionHandling to 'disable' on testwiki and beta cluster (T362324)]], [[gerrit:1155303|Stop logging $wgPHPSessionHandling warnings for now (T393963)]]

Mentioned in SAL (#wikimedia-operations) [2025-06-11T13:59:08Z] <lucaswerkmeister-wmde@deploy1003> matmarex, lucaswerkmeister-wmde: Backport for [[gerrit:1155299|Set $wgPHPSessionHandling to 'disable' on testwiki and beta cluster (T362324)]], [[gerrit:1155303|Stop logging $wgPHPSessionHandling warnings for now (T393963)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-06-11T14:08:12Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1155299|Set $wgPHPSessionHandling to 'disable' on testwiki and beta cluster (T362324)]], [[gerrit:1155303|Stop logging $wgPHPSessionHandling warnings for now (T393963)]] (duration: 11m 14s)

I finally found the time to investigate these warnings, and I think I found the bug and a fix, see T402602. I would like to re-enable these warnings for a day or two before deploying the fix that should resolve (most of) them, to get a baseline for comparison – I hope that won't be a problem, but let me know if I shouldn't do that.

I would like to re-enable these warnings for a day or two before deploying the fix that should resolve (most of) them, to get a baseline for comparison – I hope that won't be a problem, but let me know if I shouldn't do that.

Sounds fine to me from a security perspective.

I finally found the time to investigate these warnings, and I think I found the bug and a fix, see T402602. I would like to re-enable these warnings for a day or two before deploying the fix that should resolve (most of) them, to get a baseline for comparison – I hope that won't be a problem, but let me know if I shouldn't do that.

Acknowledging on behalf of Release-Engineering-Team . Making sure @Aklapper knows about this since he's on train duty next.