setup-cron.ERROR: real memory limit 756M but 512M in log

Question

I am on a shared platform and cannot change php.ini . However, the hosting platform allows me to set the memory_limit for php, which I have done - 756M. phpinfo() returns both master and local memory_limit of 756M. However, the update.log has the error: setup-cron.ERROR: Your current PHP memory limit is 512M. Magento 2 requires it to be set to 756M or more... It seems to me that the check is only looking at the value of memory_limit in php.ini, not the actual memory_limit. Is there a solution available for this?

Answer 1

I'd like to add my input here because it's too lengthy to put in a comment and I've been struggling with this issue for quite a while not being able to find a simple way to fix it. In shared hosting environments it's pretty common to set up server php.ini files to have

memory_limit = 128M or something similar

The hosting panel might provide options to increase php's memory limit as well but that is usually in the context of a vhost and not when using the CLI.

.htaccess will only help if you're starting something on the browser and php might be set up to scan for additional .user.ini or php.ini files in the script's location and that's not guaranteed either.

When you set up your cron job in the panel's environment you might get an option to choose php version to use and also add additional parameters creating a cron job that looks like

php -d memory_limit=768M "path_to_vhosts/bin/magento" cron:run

or

php -c "path/to/custom/.user.ini" "path_to_vhosts/bin/magento" cron:run

Unfortunately that didn't quite solve the issue in my case because when this command runs it invokes other php scripts using the default php settings for the child php processes causing the error again. e.g.:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 589824 bytes) in /var/www/vhosts/example.com/httpdocs/generated/metadata/crontab.php on line 2

The only solution in this case would be to modify the master value in the php.ini file used by the server but most hosts won't permit this unless you're on a VPS at least.

In such cases you apparently have two options.

1. Hardcode ini_set('memory_limit', '768M') in bin/magento
2. Hardcode ini_set('memory_limit', '768M') in app/bootstrap.php which is invoked when any command is executed.

I still haven't understood why this affects child processes that spawn from the main php script command while adding -d parameter or -c 'path/to/custom/php.ini' won't affect the child processes. I'd appreciate any input on this.

Problem is both these changes will be lost when you upgrade

In order to work around the issue I created a module instead that wraps the command cron:run creating a helper command that accepts a parameter and uses ini_set before executing the cron:run command as it would normally

use Magento\Cron\Console\Command\CronCommand;
use Magento\Framework\App\DeploymentConfig;
use Magento\Framework\App\ObjectManagerFactory;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;
class CronMemoryCommand extends CronCommand
{
    public function __construct(ObjectManagerFactory $objectManagerFactory, DeploymentConfig $deploymentConfig = null)
    {
        parent::__construct($objectManagerFactory, $deploymentConfig);
    }
    protected function configure()
    {
        parent::configure();
        $this->addOption('limit', null, InputOption::VALUE_REQUIRED);
        $this->setName('mynamespace:cron:run')
            ->setDescription('Runs jobs by schedule')
        ;
    }
    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $limit = $input->getOption('limit');
        ini_set('memory_limit', $limit);
        return parent::execute($input, $output); 
    }
}

That way you can invoke your custom command in the scheduled task like this

php "path_to_vhosts/bin/magento" mynamespace:cron:run --limit="768M"

This seems to make the errors go away while in the cron history I can see everything executing.

It should work even if things get upgraded as long as the original class exists.

I've been using this extension in shared hosting environments where nothing else worked but try it at your own risk

I also created a github repo for this for easier deployment if you want to view the full code https://github.com/ioweb-gr/magento2_cronmemory

I realize this question is pretty old but it was the first I found that closely described my problem when looking for an answer online so it might help others experiencing the same problem as mine.

Answer 2

For everyone else that is searching for an answer here, I finally found a solution (after 2 full days of troubleshooting and zero luck with technical support).

My phpinfo.php file listed a 2G memory_limit and a master value of 512M but Magento 2 readiness check kept telling me 512 was set.

Setup: Magento 2.2.5, PHP version: 7.0.3

Godaddy Business Hosting (Grow) - This is comparable to a shared hosting service but with allocated resources similar to a VPS server. You cannot modify the master php file but you can add your own .user.ini file to rewrite scripts.

The main issue is that this shared server has the option to select multiple PHP versions (MultiPHP Manager). When you select your version (in this case PHP 7.0), be sure to not to modify any of the "Switch to PHP Options" settings. Adding extensions are fine (you will need to add xsl and zip anyway to use Magento 2). If you modify any of the settings in the "PHP Options" console, it will call these master values every time. Leave them all as default (128M memory_limit, etc). In my case, I modified it to 512M from the default 128M and spent countless hours trying to troubleshoot why it was reading 512M instead of my local 2G value.

Be sure to set up the proper cron jobs to call your local .user.ini file with the correct memory_limit value.

Cron jobs looked like this:

/usr/local/bin/php -c /home/<USERNAME>/public_html/.user.ini /home/<USERNAME>/public_html/bin/magento cron:run | grep -v "Ran jobs by schedule" >> /home/<USERNAME>/public_html/var/log/magento.cron.log

/usr/local/bin/php -c /home/<USERNAME>/public_html/.user.ini /home/<USERNAME>/public_html/update/cron.php >> /home/<USERNAME>/public_html/var/log/update.cron.log

/usr/local/bin/php -c /home/<USERNAME>/public_html/.user.ini /home/<USERNAME>/public_html/bin/magento setup:cron:run >> /home/<USERNAME>/public_html/var/log/setup.cron.log

Notice the local .user.ini file being called after the master php folder instead of the file php -i was telling me to call (/opt/alt/php70/etc/php.ini).

Don't know if these two steps were necessary but I did it anyway:

Flushed cache in ssh

php /home/<USERNAME>/public_html/bin/magento cache:flush

Kill PHP Processes to restart (cPanel > PHP Processes > Kill Processes)

Note - I also updated my .htaccess file to a 2G memory_limit as well just to keep things consistent.

I checked my update.log file and the errors are no more. I also ran a readiness check and it finally passed.

Hope this helps everyone else.

Answer 3

Try to find change of memory_limit in Magento project files or htacess. If phpinfo() call you that you have 756M, then this value must be override by Magento in any place