Your current PHP memory limit is 128M, and other Magento 2 Readiness Checks

This is mainly a post-mortem from some help I provided to a patron recently.

Magento 2 uses composer to manage its various PHP packages. This includes extensions purchased or acquired via Magento’s Marketplace, as well as core Magento 2 modules and themes. In Magento’s backend at

System -> Tools -> Web Setup Wizard

you can access a GUI that will let you manager your composer packages and/or upgrade Magento via a browser. This GUI never mentions composer – instead there’s a thing gossamer applied to make things appear as though you’re just managing Magento packages.

The Web Setup Wizard involves a “readiness check” that makes sure your system is ready for an upgrade. Many users, my patron included, are seeing strange errors at this step in the Wizard, such as

Your current PHP memory limit is 128M

This is strange because Magento itself would curl up in a ball and die if you tried to run it with only 128M set as PHP’s memory limit (which is a topic for another time).

The reason the Wizard’s readiness checks fail on a running system is these checks are performed by Magento’s cron process. Magento requires you to setup three separate cron jobs.

One of the things these jobs do is output special files to the var folder

var/.update_cronjob_status 
var/.setup_cronjob_status

These files contain a JSON object with the results of PHP’s readiness checks.

Why Magento Does This

Why does the setup wizard use output from the cron jobs for its readiness checks?

Because

1. The setup wizard updates Magento via composer
2. Updating Magento via composer is a long run process
3. There no “available by default” queuing system on standard web hosts
4. So Magento uses the cron system as a poor-person’s queuing system

If you’re not familiar with queuing systems, they allow you to defer long running jobs that happen in an HTTP request, and then continue/finish the request.

Since it’s the cron system that’s actually powering the Web Setup Wizard, Magento’s smart to use the cron’s output as the basis for its readiness checks.

Why this is a Problem

Why is Magento smart to do this? Because Magento’s not all that great about telling users how they need to setup their system. So far, installing Magento 2 is a less than straight forward process, and rather than build an application with a simple bullet proof installer, Magento Inc. relies on persnickety, easy to get wrong instructions on its developer documentation site.

It’s surprisingly easy to setup a cron job that points at the wrong version of PHP, or a version of PHP that uses a different ini file (with different settings), or a under a user account that runs a different PHP thanks to path variables. This is exacerbated by confusing setup instructions like this

$ crontab -u <Magento file system owner user name> -e

that do little to explain what a Magento file system owner user name is, or how Magento should be setup.

Solving the Problem

If you’re stuck on readiness check problems, step one should be to manually inspect the

var/.setup_cronjob_status

file. If that file’s not there, you need to setup your cron jobs.

If the failures in that file match the failures you’re seeing the GUI, then your cron jobs are setup to point to a different PHP binary and/or PHP configuration. Log in as whatever user your cron jobs are running as, and trying running the job yourself and diagnosing which php binary your jobs point at and the .ini files that binary uses

$ /path/to/php/listed/in/cron/php --ini

This is usually enough to get to the root of the problem, and get your cron jobs running with the proper PHP for Magento 2.