⚓ T146285 Switch mwscript from Zend PHP5 to default php alternative (e.g. HHVM or PHP7)

	Subject	Repo	Branch	Lines +/-
	Stop forcing php5 in `mwscript`	operations/puppet	production	+1 -1

Status	Subtype	Assigned	Task
Resolved		Legoktm	T75901 Drop PHP 5.3 support
Declined		• demon	T91590 [Spike] Try out hack (<?hh) for mediawiki-config
Resolved		Joe	T104147 can we get rid of rsvg security patch?
Resolved		Reedy	T94149 Get rid of Zend 5.5 tests for wmf branches
Resolved		None	T86081 Complete the use of HHVM over Zend PHP on the Wikimedia cluster
Resolved		Jdforrester-WMF	T172165 Require either PHP 7.0+ or HHVM in MW 1.31
Resolved		None	T190909 php5 is missing on deploy1001 which breaks foreachwiki & l10nupdate
Resolved		fgiunchedi	T146285 Switch mwscript from Zend PHP5 to default php alternative (e.g. HHVM or PHP7)
Resolved	PRODUCTION ERROR	EBernhardson	T132751 "Elastica: missing curl_init_pooled method" due to mwscript job running with PHP 5 on terbium
Resolved		Krenair	T125540 New version of File:Duniya Na Mane, 1937.webm
Resolved		None	T25748 Bad label on upload max filesize at upload page in spanish version
Resolved		hashar	T146286 mwscript on jessie mediawiki fails
Resolved		tstarling	T145819 Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes
Resolved		tstarling	T111441 SiteConfiguration::getConfig() does not work in Wikimedia production

hashar created this task.Sep 21 2016, 3:17 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 21 2016, 3:17 PM

hashar added subtasks: T132751: "Elastica: missing curl_init_pooled method" due to mwscript job running with PHP 5 on terbium, T125540: New version of File:Duniya Na Mane, 1937.webm, T25748: Bad label on upload max filesize at upload page in spanish version.Sep 21 2016, 3:17 PM

hashar added a parent task: T86081: Complete the use of HHVM over Zend PHP on the Wikimedia cluster.

EBernhardson updated the task description. (Show Details)Sep 21 2016, 3:23 PM

thcipriani added a subtask: T146286: mwscript on jessie mediawiki fails.Sep 21 2016, 3:25 PM

thcipriani updated the task description. (Show Details)

hashar mentioned this in T146286: mwscript on jessie mediawiki fails.Oct 11 2016, 1:35 PM

@hashar: will T146286 also solve this one?

Joe added a project: User-Joe.Oct 20 2016, 6:36 AM

hashar closed subtask T146286: mwscript on jessie mediawiki fails as Resolved.Oct 24 2016, 2:58 PM

hashar mentioned this in T153316: Clarify SWAT process for testing maintence script changes (to not use mwdebug* hosts).Dec 15 2016, 3:23 PM

T146286 was to get the PHP5 packages installed on the maintenance servers. This task is to no more use php5 in mwscript. Once done that will let us remove the Zend packages from the deployment and maintenance servers.

hashar mentioned this in T150912: Class 'Memcached' not found when running mwscript eval.php on debug servers.Feb 2 2017, 2:37 PM

hashar mentioned this in T69924: Can't enter unicode into eval.php in production ?.Feb 27 2017, 10:54 PM

hashar added a parent task: T150912: Class 'Memcached' not found when running mwscript eval.php on debug servers.Mar 7 2017, 10:34 AM

hashar mentioned this in T160669: Remove zend tests from wmf branches.Mar 17 2017, 4:01 PM

hashar mentioned this in T161520: HHVM 3.18 crashes when Cirrus tries to fetch another wiki config via maint script .Mar 27 2017, 3:41 PM

Catrope mentioned this in T159372: Flow: DateTimeZone::__construct(): Unknown or bad timezone (+00:00).Apr 18 2017, 11:31 PM

Adding deployment-systems because mwscript lives in the scap puppet module...

greg moved this task from INBOX to Backlog on the Release-Engineering-Team board.Jun 13 2017, 11:55 PM

greg edited projects, added Release-Engineering-Team (Backlog); removed Release-Engineering-Team.

Change 358896 had a related patch set uploaded (by Chad; owner: Chad):
[operations/puppet@production] Stop forcing php5 in mwscript

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

gerritbot added a project: Patch-For-Review.Jun 14 2017, 12:01 AM

WMDE-leszek subscribed.Jul 12 2017, 8:32 AM

• Phabricator_maintenance moved this task from To Triage to Backlog (Tech) on the Deployments board.Sep 26 2017, 11:27 PM

Change 358896 abandoned by Chad:
Stop forcing php5 in mwscript

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

Jdforrester-WMF renamed this task from Switch mwscript from Zend PHP5 to default php alternative (egHHVM) to Switch mwscript from Zend PHP5 to default php alternative (e.g. HHVM or PHP7).Oct 14 2017, 12:43 AM

Speaking of which, if we're moving to php7 on mwscript and off hhvm, should we also hook up mwrepl to phpdbg?

Reedy removed a project: Patch-For-Review.Oct 15 2017, 1:20 AM

Jdforrester-WMF mentioned this in T178538: Bump PHP requirement to 5.6 in 1.31.Oct 18 2017, 10:26 PM

I am fine with https://gerrit.wikimedia.org/r/#/c/358896/ would want to schedule it and have a few people around when it is deployed.

@Krinkle pointed at T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes, but I don't think it is much of an issue.

In T146285#3728364, @hashar wrote:

@Krinkle pointed at T145819, but I don't think it is much of an issue.

I haven't confirmed it for myself, but if the issue as described is accurate and still true, I think it is very much an issue. The bug report says that 1) primary functionality on one of our sites uses the job queue, 2) said functionality dispatches a job that depends on maintenance/getConfiguration.php, 3) mwscript getConfiguration breaks with a fatal error on HHVM.

The fatal error happens because HHVM needs to be able to update its bytecode cache at any time if a PHP file changed since the last time it was invoked. T145819#3662129 mentions an idea of having Scap3 update the bytecode during each deployment. I don't think that's feasible for us. HHVM must be able to write to its bytecode cache. Warming it may save time, but I do not think it will guarantee that HHVM will never write to it. I don't think we should try to approximate all possible conditions when HHVM might need to write to its cache. Especially given how HHVM is good at optimising hot code over time.

The bug no longer happens in production because we switched mwscript to use PHP5 instead. We'll need to solve this bug before switching to HHVM. I believe we may have to conclude that the filesize restriction simply is not compatible with HHVM. Which means we need to either very significantly raise it (to allow for all normal HHVM operations), or disable it entirely until we move to PHP 7.

tstarling added a parent task: T172165: Require either PHP 7.0+ or HHVM in MW 1.31.Nov 14 2017, 9:26 AM

Krinkle added a subtask: T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes.Nov 15 2017, 7:20 AM

tstarling closed subtask T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes as Resolved.Dec 8 2017, 4:27 AM

@tstarling AIUI we should be able to switch mwscript to use 'php' instead of 'php5' now, correct?

Krinkle mentioned this in T184638: Identify uses of Zend PHP5 in Wikimedia production.Jan 10 2018, 11:03 PM

tstarling mentioned this in T161598: Monitor HHVM bytecode cache depletion on mediawiki app servers.Feb 20 2018, 4:52 AM

In T146285#3827389, @Joe wrote:

@tstarling AIUI we should be able to switch mwscript to use 'php' instead of 'php5' now, correct?

Yes

Krinkle removed a parent task: T150912: Class 'Memcached' not found when running mwscript eval.php on debug servers.Feb 20 2018, 5:02 AM

Change 358896 restored by Chad:
Stop forcing php5 in mwscript

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

Change 358896 merged by Andrew Bogott:
[operations/puppet@production] Stop forcing php5 in mwscript

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

• demon closed this task as Resolved.Mar 14 2018, 4:37 PM

• demon claimed this task.

Reverted (again) as of rOPUP48b9d506a9bb: Revert "Stop forcing php5 in `mwscript`", citing "Possible cause of slowdown in l10n rebuild stage of scap".

@demon When we try this next time, we may want to consider to not revert again, but instead opt-out using PHP=php5 for individual scripts, such as for l10n. That way we can at least continue rolling out progressively and keep tabs on individual issues. It will also mean we can continue to find potential issues with other scripts and crons, which right now can't happen.