Page MenuHomePhabricator

Switch mwscript from Zend PHP5 to default php alternative (e.g. HHVM or PHP7)
Closed, ResolvedPublic


mwscript has been hardcoded to use php5 it should use php and thus HHVM when host is set to default to it.

The reason we still use Zend is there was some code (unknown which) that was erroring out in hhvm during scap. The fix was to hardcode php5 back in February with

I don't know whether the issue is actually fixed in HHVM (or the mediawiki codebase?)

Another issue I have spotted is PHP getop() being apparently slightly different. Eg: T125540 or T125748.

When creating a deployment server with Jessie (which has HHVM), scap fails to run ExtensionMessages-master.php because the Zend extensions for Memcached or Redis are no more installed (T146286).

Related Objects

Event Timeline

elukey triaged this task as Medium priority.Oct 19 2016, 12:42 PM
elukey subscribed.

@hashar: will T146286 also solve this one?

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.

greg subscribed.

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

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

Change 358896 abandoned by Chad:
Stop forcing php5 in mwscript

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?

@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 AIUI we should be able to switch mwscript to use 'php' instead of 'php5' now, correct?

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


Change 358896 restored by Chad:
Stop forcing php5 in mwscript

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

demon claimed this task.
Krinkle reopened this task as Open.EditedMar 21 2018, 3:27 AM

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.

demon subscribed.