Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment #1
Owen Barton CreditAttribution: Owen Barton commentedYou 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.
Comment #2
asb CreditAttribution: asb commented... or you could ignore php.ini and add something like
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
Comment #3
robertgarrigos CreditAttribution: robertgarrigos commentedahhh that was the problem, different php.ini used by the command line. Solved by adding the ini_set function in settings.
many thanks.
Comment #5
winston CreditAttribution: winston commentedSorry 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!
Comment #6
asb CreditAttribution: asb commented> 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
Comment #7
winston CreditAttribution: winston commented> 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.
Comment #8
Owen Barton CreditAttribution: Owen Barton commentedwinston - 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.
Comment #9
winston CreditAttribution: winston commentedThank 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.
Comment #10
Owen Barton CreditAttribution: Owen Barton commentedThe "(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.
Comment #11
winston CreditAttribution: winston commentedThe 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.
Comment #12
Owen Barton CreditAttribution: Owen Barton commentedOK, 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".
Comment #13
winston CreditAttribution: winston commentedOwen, 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.
Comment #14
winston CreditAttribution: winston commentedComment #15
Gerald Mengisen CreditAttribution: Gerald Mengisen commented@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'
Comment #16
winston CreditAttribution: winston commentedNo, 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.
Comment #17
hutch CreditAttribution: hutch commentedIn 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
Comment #18
macattack2k CreditAttribution: macattack2k commentedI'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.
Comment #19
rsvelko CreditAttribution: rsvelko commentedNobody 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.
Comment #20
rsvelko CreditAttribution: rsvelko commentedthe cause/solution is almost always to look into the php-cli conf files... like #2 says...
Comment #21
winston CreditAttribution: winston commented@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.
Comment #22
rsvelko CreditAttribution: rsvelko commentednobody is perfect, and drush is not one of the most used drupal things.. Surely one of the cool-est... I hope this resolves soon.
Comment #23
winston CreditAttribution: winston commentedWell, 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.
Comment #24
xurizaemonComment #25
ShaunDychko CreditAttribution: ShaunDychko commentedJust 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.
Comment #26
sraisz CreditAttribution: sraisz commentedTo 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.
Comment #27
Daeluin CreditAttribution: Daeluin commentedGetting 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
php --info | grep memory_limit
default/settings.php
Also tried running with php -n (default 128M) and explicitly setting memory_limit.
everything results in:
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.
Comment #28
Daeluin CreditAttribution: Daeluin commentedOk, 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
Comment #29
hansrossel CreditAttribution: hansrossel commentedThe 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.
Comment #30
Rade CreditAttribution: Rade commentedI 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..
Comment #31
xurizaemonTo test what memory limit Drush will see, you may use
drush php-eval "phpinfo()" | grep memory
instead ofphp --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.
Comment #32
3rdLOF CreditAttribution: 3rdLOF commentedWell, 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.
Comment #33
dominikb1888 CreditAttribution: dominikb1888 commentedChanging 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?
Comment #34
mlima CreditAttribution: mlima commentedSolved this issue updating the CLI php.ini memory size.
Comment #35
PalPeet CreditAttribution: PalPeet commentedI 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?
Comment #36
PalPeet CreditAttribution: PalPeet commentedI undestand more and more that the problem is with the hosting company, not with drupal.. Jeeeezzz needed to know that before hand.
Comment #37
PalPeet CreditAttribution: PalPeet commentedComment #38
scuba_flyI can confirm setting memory limit in cli php.ini to -1 fixes the problem for me.
Comment #39
kylebehse CreditAttribution: kylebehse commented#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)
Comment #40
DrCord CreditAttribution: DrCord commentedThe solution in #2 fixed this problem for me.
Comment #41
jdrefahl CreditAttribution: jdrefahl as a volunteer and commentedJust 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.
Comment #42
ressa CreditAttribution: ressa at Ardea commentedI 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 errorYour memory limit is set to 32M;
. I first tried setting the memory_limit in ~/.drush/drush.ini which didn't work, but addingini_set('memory_limit', '512M');
to settings.php fixed it (thanks @asb from #2) and I can now rundrush cc all
.