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

Owen Barton’s picture

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.

asb’s picture

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

robertgarrigos’s picture

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.

winston’s picture

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!

asb’s picture

> 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

winston’s picture

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

Owen Barton’s picture

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.

winston’s picture

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.

Owen Barton’s picture

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.

winston’s picture

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.

Owen Barton’s picture

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

winston’s picture

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.

winston’s picture

Status: Active » Postponed (maintainer needs more info)
Gerald Mengisen’s picture

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

winston’s picture

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.

hutch’s picture

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

macattack2k’s picture

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.

rsvelko’s picture

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.

rsvelko’s picture

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

winston’s picture

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

rsvelko’s picture

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.

winston’s picture

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.

xurizaemon’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)
ShaunDychko’s picture

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.

sraisz’s picture

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.

Daeluin’s picture

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.

Daeluin’s picture

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

hansrossel’s picture

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.

Rade’s picture

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

xurizaemon’s picture

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.

3rdLOF’s picture

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.

dominikb1888’s picture

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?

mlima’s picture

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

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

PalPeet’s picture

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?

PalPeet’s picture

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

PalPeet’s picture

scuba_fly’s picture

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

kylebehse’s picture

Issue summary: View changes

#28 worked for me. Turn off "Shell fork bomb protection" in WHM, then close and reopen shell. Worked perfect.

Daeluin, if you figure out a way to turn this back on and just change the setting so something that can handle Drush, I would love to know! Thanks!

(drush-7.x-5.9 ; WHM-CLOUDLINUX 5.10 x86_64 ; cPanel-11.38.2 ; PHP-5.3; SQL-5.0.96)

DrCord’s picture

The solution in #2 fixed this problem for me.

jdrefahl’s picture

Just FYI. After trying all these I found that one must edit the "memory_limit" within the php.ini within "/etc/php5/apache2" and/or "/etc/php5/cli" (in my case 128M). Make sure you use "128M" and not "128MB". This seemed to be my problem.

ressa’s picture

I just ran into this on cPanel hosting after updating to PHP 7.2 under MultiPHP Manager, and setting memory_limit to 512M under MultiPHP INI Editor. The config definitions were written to php.ini in Drupal root, as well as appended to .htaccess (not overwritten) and memory_limit was even 512M on the status page (/admin/reports/status).

Still after running drush cc all I got the error Your memory limit is set to 32M;. I first tried setting the memory_limit in ~/.drush/drush.ini which didn't work, but adding ini_set('memory_limit', '512M'); to settings.php fixed it (thanks @asb from #2) and I can now run drush cc all.