allowed memory size error not related to php.ini, is it possible?
robertgarrigos - May 8, 2009 - 14:11
| Project: | Drush |
| Version: | All-Versions-HEAD |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Jump to:
Description
I've started to use the head version of drush and got a problem I cannot solve. Drush returns the tipical php.ini memory error "Fatal error: Allowed memory size of 16777216 bytes exhausted ". However, php is running with 1000M!! I checked the php.iuni used by the server. It's ok as it shows phpinfo. The drupal it selfs is running fine with no problems, but drush doesn't.
I have two drupals installed in this server: a drupal 6 at the root and a drupal 5 installed in a subfolder of the D6. Could this be confusing drush?
#1
You need to find and update the memory in the php.ini used by the command line php - this is normally a different file (e.g. in /etc/php5/cli, as opposed to /etc/php5/apache). YOu can also force php to use another ini file with a command line flag.
#2
... or you could ignore php.ini and add something like
ini_set('memory_limit', '150M');to your ./sites/default/settings.php.
If the "memory_limit" is set too low, Drush starts to behave quite strangely, e.g. something like "drush --verbose=2 dl zen" might simply do nothing at all. With some additional memory it starts working as advertised again, at least on my server. And yes, Drush seems to need more memory than Drupal itself (I just set up a fresh D5 site which ran fine, Drush didn't - until I significantly raised the "memory_limit").
However, it's crucial to not have remains of older Drush versions left somewhere in the contributed modules directories.
Good luck, -asb
#3
ahhh that was the problem, different php.ini used by the command line. Solved by adding the ini_set function in settings.
many thanks.
#4
Automatically closed -- issue fixed for 2 weeks with no activity.
#5
Sorry for re-opening this, but the description matches the problem I'm having. The fix suggested doesn't work for me. The behavior is quite odd.
Couple of quick notes:
I do not have any remnants of old drush or drush extras anywhere (checked and triple checked)
I am running multisite
I am running drush from within the drupal dir.
Names of my site, etc. in the below were changed to protect the clueless (namely me)
Here is the command line where I'm getting an error (along with the error)
So that looks like it is saying there is 12M allocated and it want's another 123K and is failing. So first thing I look at is what do I have on my command line. So here is the next command I run...
OK, so looks like I'm running a nice new version of the cli php. So far so good. Next up, check what php.ini file php cli appears to be using...
And a quick inspection of this file with 'less /usr/local/lib/php.ini' reveals the following memory limit...
/me now cries in beer.
Where did I go wrong? Looks like php cli thinks it has 64M, but drush is failing with an error that it only has 12M.
OK, so here is one more command (same as first but with -v) in case it helps...
All that "cannot modify header information". Does that suggest that drush is not using php cli? How could that be?
/me very confused.
If anyone helps I'll be happy to document this somewhere for other sad souls like me!
#6
> I am running drush from within the drupal dir.
Why would you do this?
> So that looks like it is saying there is 12M allocated and it want's another 123K and is failing.
There is an "Local Value" and a "Master Value" for PHP's memory limit, you're only giving us the Master value. What is the output of phpinfo() respectively /admin/logs/systeminfo/php (if you have the systeminfo module installed)?
Have you checked #2?
Greetings, -asb
#7
> Why would you do this?
Um, because the readme says to ;)
I didn't say I installed it there. I followed the instructions in the readme to put it outside the drupal folders and create a ln to it on my path, etc.
> There is an "Local Value" and a "Master Value" for PHP's memory limit
OK, so I went to /admin/logs/systeminfo/php for the site in question. Both Master and Local show 64M.
> Have you checked #2?
Yes, since I'm running a multisite I tried #2 on both /sites/default/settings.php (had to create one as I don't otherwise have a default site), and /sites/example.com/settings.php. I had _very_ high hopes on that one, but same exact drush output :(
asb, very much appreciate the quick response. Do let me know if you have any other ideas.
#8
winston - can you try running drush using:
php /path/to/drush/drush.php -v -l example.com status
The drush wrapper has some logic to try and find the best php version, and it appears that it is finding a different one to the one you get when you just run "php". Running "php drush.php" can verify this.
#9
Thank you for the suggestion Owen. Unfortunately that still doesn't work. The weird thing is the error reports don't make sense...
So it is saying I'm running out with it trying to allocate only 7.6K with a total allocated of about 12M. But when I do "php --ini" it says it is using /usr/local/lib/php.ini and when I view that ini file it has a memory_limit of 64M. My site has a limit of 96M set in the settings.php, the php.ini being used by apache process is set to 64M. So where on earth could this 12M memory limit be coming from?
Your post pointed me to look at the wrapper file (the bash script drush). So I found the line where it is checking the environment to see what php is there. I found this line...
So I ran that at my command prompt and got...
So that looks good yes?
As one last resort I tried "php-cli /path/to/drush/drush.php -v -l example.com status" (explicitly calling php-cli). End result was exactly the same error.
Anyway, if anyone has any additional troubleshooting suggestions I'm all ears.
Thanks to everyone who responded so far.
#10
The "(tried to allocate 7680 bytes)" part is a red herring - php allocates memory as it needs it, up to the limit - so it is only the last allocation that will fail, which in your case happens to that 7680 bytes will push it over the limit.
Not sure where to go from here. What happens if you run "php -d memory_limit=64M /path/to/drush/drush.php -v -l example.com status", and what happens if you run "php -c /usr/local/lib/php.ini /path/to/drush/drush.php -v -l example.com status"?
Another approach could be to try searching the filesystem for php (binary) and php.ini files, and see if any of those are tucked away in an unexpected place.
#11
The strangeness continues
Gave me...
Fatal error: Out of memory (allocated 10485760) (tried to allocate 7680 bytes) in /home/winstonp/public_html/livesites/modules/upload/upload.module on line 45
Similar, but running out at a lower amount of memory.
Gave me...
Fatal error: Out of memory (allocated 12058624) (tried to allocate 2 bytes) in /home/winstonp/public_html/livesites/sites/all/modules/cck/content.module on line 31
which is identical to before.
#12
OK, so I am pretty much out of ideas here - my only other guess is that perhaps suhosin.memory_limit (or perhaps some hard coded compile time limit) is set, or for some reason has a non-standard default - perhaps try "php -d memory_limit=64M -d suhosin.memory_limit=64M /path/to/drush/drush.php -v -l example.com status".
#13
Owen, I may have found a solution that has nothing to do with memory. I have to check in with my hosting service. Something funky with the way it connects to mysql.
Hard to see how this is related, but I'll come back to this issue when I have more information.
Perhaps it will become a documentation page for someone else.
Still don't understand why it is being reported as a memory problem though. suhosin.memory_limit is also high. I look throughout php.ini for any other memory limit lines.
Anyway, thanks very much for your suggestions so far. I'll update this thread prob later in the week.
#14
#15
@winston
I have the same problem as you - do you have an update?
I also thought the Drupal Tweaks module could offer a solution, but there I ran into a different problem: #537978: "Fatal error: Call to undefined function theme()" with 'drush status'
#16
No, afraid not. I gave up on this for now. I'm able to get drush working on my dev machine which is good enough for now.
#17
In my experience on Debian php-cli's php.ini file is only applied to root, ordinary users get another set of defaults which can be overridden in .htaccess and probably in settings.php
#18
I'm having the same issue. So it's still out there...
Alternatively, does anyone have a good hosting site that is drupal (and drush!) friendly? I've tried GoDaddy and JustHost with a bunch of problems. Some fixable and some not.
I understand that Drupal is usually on the cutting edge of technology and therefore needs cutting edge hosting services. Once again, I'm looking for a host that I can fool around with Drupal 7 and Drush with.
#19
Nobody here has posted some feedback from the hosting companies' support, so far. Come on :) They know their systems better than drush maintainers...
It is obvious that this is because of the system setup. Nobody with a standart linux/win srv install can reproduce it.
#20
the cause/solution is almost always to look into the php-cli conf files... like #2 says...
#21
@rsvelko, you are absolutely right. Just haven't had time. As soon as I do I'll ask my hosting company to research this. They advertise being drupal friendly which I will tell them flat out they aren't if they don't have it set up for drush to perform well. However, I won't name them here as I haven't informed them of my problem yet! Hardly fair till I give them a fair go. Will report back on the result to this thread.
#22
nobody is perfect, and drush is not one of the most used drupal things.. Surely one of the cool-est... I hope this resolves soon.