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

climagento2memory

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?

Best Answer

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.

Related Topic