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?

Comments

Status:Active» Fixed

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.

... 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

ahhh that was the problem, different php.ini used by the command line. Solved by adding the ini_set function in settings.

many thanks.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

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)

drush -l example.com status
Fatal error: Out of memory (allocated 12058624) (tried to allocate 122880 bytes) in /home/myaccount/public_html/livesites/sites/all/modules/cck/content.module on line 1082
Drush command could not be completed. [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...

php --version
PHP 5.2.9 (cli) (built: Jun 14 2009 11:32:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

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...

php --ini
Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: /usr/local/lib/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)

And a quick inspection of this file with 'less /usr/local/lib/php.ini' reveals the following memory limit...

memory_limit = 64M

/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...

drush -v -l example.com status
Initialized Drupal 6.12 root directory at [notice]
/home/myaccount/public_html/livesites
Initialized Drupal site at sites.example.com [notice]
session_start(): Cannot send session cookie - headers already sent by[warning]
(output started at
/home/myaccount/bin/dutils/drush/includes/drush.inc:439)
session_start(): Cannot send session cache limiter - headers already [warning]
sent (output started at
/home/myaccount/bin/dutils/drush/includes/drush.inc:439)
Cannot modify header information - headers already sent by (output [warning]
started at /home/myaccount/bin/dutils/drush/includes/drush.inc:439)
Cannot modify header information - headers already sent by (output [warning]
started at /home/myaccount/bin/dutils/drush/includes/drush.inc:439)
Cannot modify header information - headers already sent by (output [warning]
started at /home/myaccount/bin/dutils/drush/includes/drush.inc:439)
Cannot modify header information - headers already sent by (output [warning]
started at /home/myaccount/bin/dutils/drush/includes/drush.inc:439)

Fatal error: Out of memory (allocated 12058624) (tried to allocate 122880 bytes) in /home/myaccount/public_html/livesites/sites/all/modules/cck/content.module on line 1082
Drush command could not be completed. [error]

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!

> 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

> Why would you do this?

Um, because the readme says to ;)

Start using drush by running "drush" from your Drupal root directory.

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.

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.

Thank you for the suggestion Owen. Unfortunately that still doesn't work. The weird thing is the error reports don't make sense...

Fatal error: Out of memory (allocated 12058624) (tried to allocate 7680 bytes) in /home/myaccount/public_html/livesites/sites/all/modules/cck/content.module on line 18

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...

/usr/bin/env php-cli -v

So I ran that at my command prompt and got...

PHP 5.2.9 (cli) (built: Jun 14 2009 11:32:07)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH

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.

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.

The strangeness continues

php -d memory_limit=64M /path/to/drush/drush.php -v -l example.com status

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.

php -c /usr/local/lib/php.ini /path/to/drush/drush.php -v -l example.com status

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.

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".

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.

Status:Active» Postponed (maintainer needs more info)

@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'

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.

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

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.

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.

the cause/solution is almost always to look into the php-cli conf files... like #2 says...

@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.

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.

Well, my host fixed this error, but didn't tell me how. I asked, but didn't get an answer.

So it's fixed for me, but I'm afraid I don't know how.

Status:Postponed (maintainer needs more info)» Closed (fixed)

Just making it crystal clear for new users. Comment #1 worked for me:
modify the file /etc/php5/cli/php.ini
search for "memory_limit" and change it from the default of 32M to something larger.

To add to the issue:

I just installed latest drush. I am running multi-site drupal 6.15.

When I invoke drush from the /sites folder I get no error, but it only recognizes the modues enabled in the default site

when I move to one of the other sites and run drush I get the fatal error.

I edited the settings.php file in the site folder (as suggested in #2 ) and it worked.

Getting the same issues here as #5.

Tried setting the memory_limit pretty much every way suggested above, but it's throwing errors at 15M.

Verified by starting with an empty drupal install and slowly enabled modules until it broke the 15M limit. Before that it ran OK. Every site gives errors at 15728640.

We have many drupal sites on this server (stormondemand/liquidweb) and they all suffer. We have a fairly identical setup on hostgator and it's fine. We opened a ticket with liquid and they are unable to determine what the problem is.

This memory error doesn't exist when run as root. Seems like there's something enforcing this limit for normal users... cPanel?

Using suphp but not suhosin.

php --ini

Configuration File (php.ini) Path: /usr/local/lib
Loaded Configuration File: /usr/local/lib/php-cli.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed: (none)

php --info | grep memory_limit

memory_limit => 200M => 200M

default/settings.php

ini_set('memory_limit', '200M');

Also tried running with php -n (default 128M) and explicitly setting memory_limit.

everything results in:

drush st
Initialized Drupal 6.17 root directory at /home/drush/public_html [notice]
Initialized Drupal site default at sites/default [notice]
session_start(): Cannot send session cookie - headers already sent by (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:1143 [warning]
session_start(): Cannot send session cache limiter - headers already sent (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:1143 [warning]
Cannot modify header information - headers already sent by (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:709 [warning]
Cannot modify header information - headers already sent by (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:710 [warning]
Cannot modify header information - headers already sent by (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:711 [warning]
Cannot modify header information - headers already sent by (output started at /usr/local/drush/includes/drush.inc:794) bootstrap.inc:712 [warning]

Fatal error: Out of memory (allocated 15728640) (tried to allocate 94196 bytes) in /home/drush/public_html/includes/bootstrap.inc on line 690
Drush command could not be completed.

Same error for all sites on this server, gives error on different files on different sites.

This only began last week. We didn't change anything, it'd been working just find up to that point. Our host says they didn't change anything either. Same drupal, same drush. Thought it could've been a cPanel update, but then it would've affected our hostgator server also.

We use drush extensively across our sites, so this is quite the impediment.

Ok, I was able to fix this by turning off the Shell Fork Bomb Protection in cPanel. The default limits are a bit too low for drush, I'll be tweaking them!

http://etwiki.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/ShellFork

The solution of #17 solved it for me,
- "drush status" gives the out of memory fatal error
- "sudo drush status" works ok

But I also have cpanel and Shell Fork Bomb Protection on. Might be that this Protection is not applied if you sudo.

Component:Code» PM (dl, en, up ...)

I ran into the exact same problem today.

The weird thing is, I have two accounts on the same webhost. On the newer account drush works fine, on the older one I encounter this memory error.
Might have to check with the hosting company's support..

Title:allowed memory size error not related to php.ini, is it possible?allowed memory size error: Drush CLI may use different php settings from "regular" Drupal
Component:PM (dl, en, up ...)» Documentation
Category:bug» support

To test what memory limit Drush will see, you may use drush php-eval "phpinfo()" | grep memory instead of php --info.

It's not just php.ini that counts. PHP config settings can be set in multiple places. Settings on the same server may or may not take effect or not depending on the calling user, script location, PHP version and binary (CLI, CGI, apache module etc) involved. Testing php --info may not show you the relevant values because it may not load settings specific to your Drupal site. Testing as a different user, or calling drush cron from CLI vs cron.php from HTTP may also cause different PHP settings to be loaded. Code running in Drupal which sets memory_limit using ini_set() may be overriding your server settings as well.

Several of the above comments seem to be having specific issues with Drush on shared hosting environments or CPanel / WHM / etc setups. Please consult your hosting documentation if you are having similar issues, and if you are experiencing resource limits specific to Drush, when requesting support from your hosting company make sure to alert them to the fact that you are running PHP from CLI.

Well, this issue seems to continue for some of us. IN my case it is impeding me from provisioning any of the larger distros (eg: Open Atrium) through Aegir and I have looked into EVERYTHING to no avail:

A) Ubuntu 10 LTS running php 5.2.10 & Drush 3.3. This is a Linode, no shared hosting.
B) Drush is properly installed, running smooth. All drush shell commands work and all statuses check out.
C) No matter how much memory I give it it always tops it and fails at the very end. Right now running 512M and still no luck. Most users appear to be fine with 256M for an Aegir set up.
D) SIte is not in use = no traffic = only memory being used is Drush and the site's front end interface.
E) I am trying to provision a remote server from the master.

I checked everything twice x 10:

1) Memory is correctly set in PHP CLI php.ini. It is the right php.ini because any modification I do to it, Drush picks up (eg: I set it to 200M, Drush sees 200M) All checks as to which php.ini is running and point to the right file. ini_set() does not appear to be affecting or interfering with the memory setting in php cli. Running drush php-eval "phpinfo()" | grep memory confirms this.
2) I have followed the Aegir instructions for running the debug from ssh by doing: /var/aegir/drush/drush.php --uri='subdomain.domain.com' provision-verify '@subdomain.domain.com' --debug Gives out no errors and all notices, messages and bootstaps show a memory of around 4.50 to 4.67. Everything seems to check out.
3) PHP logs no errors at all.
4) When I run "top" while running Drush I can see PHP memory usage climbing in small increments of about 0.5 and it all seems to be ok until suddenly it spikes and fails.

I am, for a lack of better words, lost like a monkey with calculator.

Changing the setting in cli/php.ini back (i've changed the default value after getting another error message) to "memory_limit = -1" solves the problem for me. I am running debain sid.

Can anyone confirm?

Version:» All-versions-4.0
Component:Documentation» Config
Category:support» bug

Solved this issue updating the CLI php.ini memory size.

I have the same problem and I'm a newby under the newbies..
Now my hosting provider - shared hosting - does not let me change the memory setting in PHP. What else could be done to solve this problem?

I undestand more and more that the problem is with the hosting company, not with drupal.. Jeeeezzz needed to know that before hand.

I can confirm setting memory limit in cli php.ini to -1 fixes the problem for me.