PHP Command-line scripts are ignoring php.ini and ini_set('memory_limit',...) directives.

Question

Hello, I am facing the common "Fatal error: Out of memory (allocated 30408704) (tried to allocate 24 bytes)..." PHP Fatal error. Pages served via Apache are not exhibiting this behavior.

I've tried the following:

1. Increasing the memory_limit in php.ini to a much larger value.
2. Increasing memory_limit within the script itself via calls to ini_set('memory_limit', -1), ini_set('memory_limit', '-1'), ini_set('memory_limit', 100000000), ini_set('memory_limit', '128M'), etc.
3. unset()ing unneeded arrays and objects to encourage the garbage collector to free up memory.
4. Contacting the web host. They are normally very capable and knowledgeable, but have not been able to help me with this issue either.
5. I've tried explicitly including a php.ini file using the -c command-line flag to hand-pick specific php.ini files with various values.
6. I've tried setting memory_limit in php.ini using both raw numbers of bytes and values such as 64M, 128M, etc.
7. The hosting provider was able to run the script as root with no issues, but experiences the same issue I do when running it using my non-root user. Perhaps there is some kind of permissions issue involved?

Regardless of what I try, the error message is the same. It appears that my command line scripts are ignoring changes to memory_limit.

I tend to try to make sure my scripts are memory efficient, but I'm currently needing to parse large amounts of HTML via Simple HTML DOM and it is in the parser that I'm experiencing out of memory issues. In an attempt to reduce the memory footprint of the script, I've tried using DOMDocument instead. This does not help either. In fact, the out of memory error is now triggered elsewhere in the script.

My question: has anyone experienced this or a similar issue? Do you have any recommendations?

Thank you.

Answer 1

your PHP on cli may be using a different php.ini to your apache php. try a phpinfo() and check its using the ini file you think its using.

Answer 2

It turns out that the problem was caused by shell fork bomb protection being enabled on the server that was placing a hard memory limit on all command-line scripts. This had been enabled by my web host without my knowledge.