Memory limits prevent memory allocation errors from being displayed
Forum
  1. Forums
  2. CloudLinux and Control Panels
  3. CloudLinux and cPanel
  1. Kevin Brooks
  2. 06.02.2012
  3.  Subscribe via email
Given the way memory limits are currently implemented a program may never have the opportunity to be aware of or report an error resulting in nothing more than a blank page in a browser. That can make memory allocation related problems difficult to isolate given the lack of error reporting (by the application) and lack of user feedback (to the browser). For example, take a typical CGI application written in C that attempts to allocate memory using malloc. If the allocation is larger than is allowed by LVE limits the application is killed and has no opportunity to log an error or display an error to the user.

PHP applications, at least those running under mod_fcgid seem to be able to detect and report memory allocation errors (at this point I\'m not sure why). You\'ll typically see an error such as:

[Mon Feb 06 15:55:24 2012] [warn] [client 12.12.12.12] mod_fcgid: stderr: PHP Fatal error: Out of memory (allocated 786432) (tried to allocate 2900001 bytes) in /vhome/infra/public_html/test/mem_test.php on line 14

when PHP is denied memory due to an LVE limitation. I suspect this is because mod_fcgid is started SUID root yet is running with an EUID of the user attached to the process. As a result the process is exempt fr om LVE lim its since it was started and allocated resources as \"root\" before the EUID change occured.
Rate this post:
  1. 06.02.2012 21:02:19
  2. # 1
Igor Seletskiy Accepted Answer
Posts: 1201
Joined: 09.02.2010
0
Votes
Undo
Hi Kevin,

Yes, very much like RLimitMEM -- it is pretty confusing.
the lveinfo --by-fault=mem will get you some info, but it is not perfect.
While we plan to return info that the error was due to mem limits -- that technology will probably not work with mod_fcgid (as there is no clear way to pass info from mod_fcgid daemon to apache about the error).

Of course -- I think, the fact that we limit virtual memory instead of physical memory is even bigger problem -- but that should be addressed soon.
  1. 07.02.2012 04:02:28
  2. # 2
Kevin Brooks Accepted Answer
Posts: 14
Joined: 10.08.2010
0
Votes
Undo
Except for the fact that with RLimitMEM we were able to hack suexec to check the per user process and memory limits after the fork/exec so that it worked correctly. Unfortunately that code ever made it into Apache core and it looks like suexec is still broken. And, with RLimitMEM we were (for the most part) dealing with real memory (on BSD based distros) and could easily isolate failures to a single process since the memory limit was imposed per process not per user.

Regarding virtual memory, I couldn\'t agree with you more. Limiting virtual memory is like giving someone a car that can do 100 miles to the gallon but limiting them to 20. It really doesn\'t make any sense.

If mod_fcgid can\'t pass info to Apache then it should at least log the error itself to some mod_fcgid log. We need to be able to isolate and fix problems and without logging it can become a costly adventure.
  1. 07.02.2012 10:02:53
  2. # 3
Igor Seletskiy Accepted Answer
Posts: 1201
Joined: 09.02.2010
0
Votes
Undo
Kevin,

Yes, it is a bit easier when it is per process, as you can be sure that at least suexec will be able to execute.
Anyway -- mod_fcgid does log info about the issue, like it cannot allocate enough memory, and you can figure out if it is related to memory limits by running lveinfo --by-fault=mem
  • Page :
  • 1


There are no replies made for this post yet.
Be one of the first to reply to this post!
Guest
Submit Your Response
Upload files or images for this discussion by clicking on the upload button below. Supports gif,jpg,png,zip,rar,pdf
• Insert • Remove Upload Files (Maximum File Size: 2 MB)
Captcha
To protect the site from bots and unauthorized scripts, we require that you enter the captcha codes below before posting your question.