PHP CLI "Out of memory" error on VPS server running CentOS with cPanel
Asked Answered
F

1

9

I'm running Symfony2.1 on a hosted virtual server running CentOS with cPanel. Everything runs fine except that I can no longer use Symfony CLI commands. I'm getting this:

Fatal error: Out of memory (allocated 20185088) (tried to allocate 71 bytes)

error (for example when I try to run php app/console cache:clear --env=prod or other useful Symfony commands).

I've used the same commands through the CLI for months without any problem until a few days ago when this error came out. I haven't been able to overcome this error since then.

I want to point out that this not a PHP memory_limit related error (see below), being an "Out of memory" error and not an "Allocated memory size" error.

The exact same commands run perfectly when added to a cron job (this is the temporary workaround I'm using now), meaning that the scripts themselves are not to be blamed.

What I've tried to do so far:

  • Increase memory_limit in php.ini (or directly on the command line) : as I suspected from the type of error I'm having, this had no effect

  • Search for any other php.ini file that may overwrite this setting for the CLI : there was none

  • Monitoring memory usage with free -m : there was plenty of memory available (which was expected, as the symfony commands run perfectly through cron jobs)

  • Trying to find if WHM/cPanel might have, through an update for example, set any memory restriction for user accounts : I've found that this might be the case when using a jailed SSH shell (but thing is, I'm not, I'm using normal SSH shell), or if enabling Shell Fork Bomb protection (but no, this is disabled on my server)

  • Checking ulimit settings on my server/account with ulimit -a : there are limits, but they amount to 256M whereas my "Out of memory" error indicated that no more than 20M seem to be allowed to PHP CLI

  • Checking if there was any memory restriction somewhere in .conf files, especially in /etc/security/limits.conf: there was none

  • Checking for any other file that could set up that kind of memory restriction: this time I indeed found one, namely /usr/local/cpanel/etc/login_profile/limits.sh which seem to set such limit (ulimit -n 100 -u 35 -m 20000 -d 20000 -s 8192 -c 20000 -v unlimited 2>/dev/null) => I thought I'd finally found the culprit, as the numbers (20000) seem to correspond, but editing this file as root and logging again in my account through SSH had, again, no effect

My question :

I've now run out of options. I contacted my host but they are as clueless as I am (a lot more really, they don't even know about Symfony). Is there anyone out there who experienced the same problem?

If, by any chance, the /usr/local/cpanel/etc/login_profile/limits.sh have gotten me close to the answer, what I am missing? Do I need to reboot the server or restart cPanel, instead of just re-logging to my account?

On a side note, is this something that might-be related to a WHM/cPanel update (as stated, everything was working perfectly on the command line until a few days ago)?

Thanks for any help, and sorry for the long question.

PS: I've found other similar questions on Stack Overflow, but each of them was solved using one of the things I've already tried. So I guess I'm experiencing a different problem.

Feria answered 6/4, 2013 at 10:31 Comment(7)
It really does sound like the script is using more than PHPs memory_limit allows. Have you tried doing a php --ini to get the location of your CLI php.ini, setting memory_limit = 512M (or some other large number) then restarting apache?Extinguisher
+1 for well explained questionBencion
@ChrisMcKinnel Thank you for your answer. Yes, I did (making sure that it was indeed the CLI php.ini I was editing), but it didn't change anything. That is the reason why I seriously doubt it's a PHP memory_limit problem.Matte
How many ram do you have in your server? Do you have any swap partition? I had some similar problem before using composer update in my vps and added a swap partition solved the issue,Fulgurate
Are you running ulimit -a as the same user you are trying to run the scripts as?Lupulin
@Bruno-P Thanks, that's interesting. However I am able to run the scripts (as a cron job, they run), just not via SSH on the command line - and I've more available RAM than needed for the scripts (more than 400M)Matte
@AliGangji Thanks. Yes, I made sure of thatMatte
F
1

It turns out that following an unwanted cPanel update my SSH port was changed from the default value and I was unable to login. I restarted SSH in safe mode in order to login.

Today, on a hunch, I looked at the SSH port in /etc/ssh/sshd-config, restarted SSH in "normal" mode, and logged in with the correct port: the scripts now run perfectly.

So the cause was using SSH in safe mode, just that. Hopefully this very specific problem will be useful to someone else: never use SSH safe mode for daily use unless you absolutely need to.

Feria answered 7/4, 2013 at 7:25 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.