Aegir 'Install' task exhausts memory for 2.0b9 and 2.0b12

I will look into this, I am guessing the profile gets stuck in a loop somehow. Can you verify that this still happens with Beta13?

Thanks,
Richard

I had the same error on a linode machine with 512MB. Increasing it to 1536MB took care of the issues.

Your cli memory should be set to -1 (unlimited), too.

Memory_limit issue appeared again and again during Installing openScholar App V.2.0-beta14

Hello All,

Problem: Installing openScholar latest version and Drupal6 on our server, and I encountered the following problems for many times:
After I have tried all fixes suggested by many web pages, but the White web page was shown during installing. The error message says the following:
: " PHP Fatal error: Allowed memory size of 67108864 bytes exhausted"

I have read most of the solutions on the web to the above problems, and done the solutions given at these pages:
http://drupal.org/node/1350462
http://forum.civicrm.org/index.php?topic=17481.0
http://ftp.drupal.org/files/videocasts/Install-D6.mp4
http://groups.drupal.org/node/104979
http://drupal.org/documentation/install/beginners
http://drupal.org/server-permissions
http://drupal.org/documentation/install/beginners
http://groups.drupal.org/node/201128

I made sure that I had done the following things before this posting:
* Done this, not solved

I did the following in php.ini file and ..htaccess file
memory_limit = 128M

Done this, not solved

http://drupal.org/node/158043

Output Buffering
Some modules need output buffering turned on.
To do this, try adding these lines to your .htaccess file (normally located in your root directory:

php_value output_buffering On
php_value output_handler mb_output_handler
* Done this, not solved

Clearing the Cache Table
Depending on the problem, clearing the cache table (via phpmyadmin for example) can resolve a WSOD.
* Done this, not solved

PHP pages do not display
https://my.hostmonster.com/cgi/help/281
* Problem: " PHP Fatal error: Allowed memory size of 67108864 bytes exhausted"

Used these solutions suggested at these pages: did not work for me
http://drupal.org/node/1350462
http://forum.civicrm.org/index.php?topic=17481.0

All the above have not fixed the above install problems. Now, I really wish to hear any suggestions what I have done wrong here. Thanks a lot.

Helen

If you are exhausting 67108864 bytes (that is 2^26) then your memory limit on your machine is still set to 64MB. Did you restart apache after you increased the memory limit? And 128MB may not be enough, anyway. Jack it up to 196MB or even 256MB

Hello Steve,

Thank you very much for the advice.

#
===========================================
If you are exhausting 67108864 bytes (that is 2^26) then your memory limit on your machine is still set to 64MB. Did you restart apache after you increased the memory limit?
======================================================
I did the above on our Web server hosted by one top web hosting company, we bought the shared hosting service. According to the advice of this hosting company, the clients should create their own php.ini file, and the max memory limit 128 is good enough.

#
==========================================
And 128MB may not be enough, anyway. Jack it up to 196MB or even 256MB
===================================
I tried 256MB, the same situation appeared again.

Any other advice?

Helen

How many bytes is it exhausting at now? What is the exact error message you are getting?

Error Messages after memory increased to 256MB

Hello Steve,

Really appreciated your timely followup. I have increased memory to 256MB and followed the needed procedures, and I just tried to install openScholar App now, and got the following Error Message, not clear why two error messages are different:

PhP error message:
======================================
PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 14127 bytes) in /.../openScholar/SCHOLAR-2-0-BETA14/includes/database.mysqli.inc on line 329 ;

PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 2907 bytes) in /.../openScholar/SCHOLAR-2-0-BETA14/includes/database.mysqli.inc on line 329
============================================

Our Web server also gave MAIN error_log:

Thank you very much,

Helen

As I've already pointed out, you may think you have increased you memory limit to 256MB but you haven't. That's evident from your error message which clearly states you are exhausting 64MB, or more precisely, 67108864 bytes.

Consult with your host to determine how to make the new setting take effect.

Re: Memory limit issue is fixed, but white web page is still displayed during installing

Hello Steve,

Thank you very much for your advice. Have worked with our hosting company, now memory limit issue is fixed. But, we still got the following message, our hosting company said the following is not server problem:

The white page was still shown and got the following php error message:
==================================
[27-Feb] PHP Fatal error: Call to undefined function os_include() in /....../openScholar/SCHOLAR-2-0-BETA14/profiles/openscholar/openscholar.profile on line 497
==========================

Any suggestions?

That's a bug in the open scholar profile install script. I don't have time to research that. You should consult the open scholar community for further assistance.

Testing this out with the application that's failing has two major downsides as compared to testing it with an extremely simple PHP script. First of all, it takes much longer to get any complicated application to initialize itself and report the result. And secondly, if you need help from your system administrator, he's not going to want to debug through your large application to figure out what's going wrong.

To figure out why your attempt to increase PHP's memory isn't working, you're much better off testing with a short, simple snippet of PHP code. Copy the following code into a .php file in your DOCUMENT_ROOT. Then navigate to that file in a browser. For example, if your domain is xyz.com, save the script below in a file called foo.php. Then navigate to http://xyz.com/foo.php.

<html>
<body>
memory_limit = <?php echo(ini_get('memory_limit')) ?>
</body>
</html>

This will tell you very quickly whether or not your attempt to increase the amount of memory actually succeeded.

Before you navigate to http://xyz.com/foo.php, set memory_limit in php.ini to some oddball value. For example, 67 is a prime number -- not the sort of value anyone would ever set for memory_limit. The purpose here is not to set memory_limit to the final value you desire, but rather to set it to some unique value so you can be sure whether PHP's getting your value or picking it up from some other file. So, if you replace the memory_limit line in your php.ini with:

memory_limit = 67M;

and then navigate to http://xyz.com/foo.php, you'll know instantly whether or not the PHP interpreter is seeing the value you edit into that file. And if it's not getting the value from that file, being able to point your sysadmins at this very simple test code is much more likely to get a useful response than pointing them at the entire Open Scholar distribution.

Once you've solved the problem of how to get PHP to read the right value from the right file at the right time, then you can edit in whatever value you think is appropriate, run this script to verify that it's been set, and then retry Open Scholar.

The most likely reasons PHP isn't seeing your memory_limit value are: 1) PHP isn't configured to look for your php.ini file in the location where you've got it, or 2) the executable that PHP's linked into needs to be restarted to cause it to re-read the php.ini file.

There are three ways I know of that your server might be configured to invoke PHP from Apache:

1) It's compiled as a shared object (.so file) and at runtime it's part of the same process as Apache,
2) The PHP executable is invoked by Apache via CGI,
3) The PHP executable is invoked by Apache via FastCGI.

Although #2 would not require any process to be restarted to get PHP to re-read the php.ini file, hardly anybody does #2 anymore because it's just too much overhead to do a fork() and exec() for each HTTP request.

Both #1 and #3 require some process to be notified somehow that they need to re-read the php.ini file. Some Unix daemons can be notified to re-read their config files by sending them a SIGHUP. I don't know if FastCGI implementations recognize SIGHUP or not. But for either #1 or #3, killing the appropriate process and starting the same process up again will definitely force the config file to be re-read.

In the time it took me to compose this, the original poster has solved their memory_limit problem. But I'm going to leave this here anyway in the hope that it might be helpful to anyone else with memory_limit issues.

Hello Mark,

Thank you very much for your detailed solution. I found that your solution is very helpful to those who are new to php applications.

Noted Aegir version (1.5)