In order to resolve this issue I had to make sure there was over 1 gig of memory available.

I was also having this issue but increasing the PHP memory_limit solved the problem.

Same here:

PHP Fatal error:  Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943
Stack trace:
#0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///usr/loc...', 943, Array)
#1 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(943): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)
#2 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(848): Symfony\Component\Console\Application->getSttyColumns()
#3 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(771): Symfony\Component\Console\Application->getTerminalWidth()
#4 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(113): Symfony\Component\Console\Application->renderException(Object(ErrorException), Object(Symfo in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

ErrorException: proc_open(): fork failed - Cannot allocate memory in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php on line 943

Call Stack:
    0.0001     620632   1. {main}() /usr/local/bin/composer:0
    0.0032     727952   2. require('phar:///usr/local/bin/composer/bin/composer') /usr/local/bin/composer:15
    0.0187    3168240   3. Composer\Console\Application->run() phar:///usr/local/bin/composer/bin/composer:13
    0.0211    3485008   4. Symfony\Component\Console\Application->run() phar:///usr/local/bin/composer/src/Composer/Console/Application.php:66
   13.2099  135622120   5. Symfony\Component\Console\Application->renderException() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:113
   13.2099  135622968   6. Symfony\Component\Console\Application->getTerminalWidth() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:771
   13.2099  135623064   7. Symfony\Component\Console\Application->getSttyColumns() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:848
   13.2099  135625208   8. proc_open() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943
   13.2100  135626416   9. Composer\Util\ErrorHandler::handle() phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:943

More info about the system:

php -v
PHP 5.3.10 (cli) (built: Feb 20 2012 16:56:36) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans

Got the same error two times, but can say: It work around an hour ago (without any change on the setup) and now in the third try it works again (without any change at all).

$ php -v
PHP 5.4.4-4~precise+1 (cli) (built: Aug  6 2012 13:01:46) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

Update:

OK, forget it. I forgot to enable the swap again... The machine _really_ ran out of memory...

Had the same issue when trying to do a deployment to an Amazon AWS EC2 Micro instance. These instances have only 613MB of memory in total so composer fails to allocate enough memory for an update to run. Upgrading to a Small instance with 1.7GB of total memory got rid of the issue.

I have the same issue .... does composer really need so much memory? :-O

I guess it's not composer itself, but anyway: The micro instances on ec2 doesn't have _any_ swap memory (by default) and so the OS kicks the processes, if it runs out of memory. The better solution instead of upgrading to small (because it costs more) is to create a file based swap (at least temporary)

For example.

# /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
# /sbin/mkswap /var/swap.1
# /sbin/swapon /var/swap.1

613M is very less and remember, that not only PHP consumes it. I don't think one can blame composer for it. Can somebody close this issue?

People using micro instances should not have problems anymore after updating composer and updating your lock file to the new format, see #1109. If you have memory issues with other things than install, see #600.

I am running into this issue again. Here is my Dump:

PHP Fatal error:  Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:969
Stack trace:
#0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///vagrant...', 969, Array)
#1 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(969): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)
#2 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(874): Symfony\Component\Console\Application->getSttyColumns()
#3 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(798): Symfony\Component\Console\Application->getTerminalWidth()
#4 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(113): Symfony\Component\Console\Application->re in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php on line 969

Doing a Dry-Run with Profiling returns the following mem usage info:

Memory usage: 25.95MB (peak: 67.15MB), time: 9.21s

Hi,

Just a guess: Do you running this on a AWS-micro? Do you have a swap
enabled?

Regards,
Sebastian

2012/12/20 Dan Horrigan [email protected]

I am running into this issue again. Here is my Dump:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:969
Stack trace:

0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///vagrant...', 969, Array)

1 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(969): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)

2 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(874): Symfony\Component\Console\Application->getSttyColumns()

3 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(798): Symfony\Component\Console\Application->getTerminalWidth()

4 phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php(113): Symfony\Component\Console\Application->re in phar:///vagrant/www/api-v3/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php on line 969

Doing a Dry-Run with Profiling returns the following mem usage info:

Memory usage: 25.95MB (peak: 67.15MB), time: 9.21s

—
Reply to this email directly or view it on GitHubhttps://github.com/composer/composer/issues/945#issuecomment-11587234.

github.com/KingCrunch

@dhorrigan ouch according to the stack trace it looks like the fatal error was triggered while rendering an exception (since that uses proc_open to check for your terminal width). Looks like it's not a php memory limit but rather the machine's memory that ran out, so I would suggest clearing other things, and running it with install instead of update if you can run update somewhere else that has more memory. install from lock file uses very little memory.

I am running this in a Vagrant box, and there is quite a bit running on it, but this is the first time I have seen it. I will try re-building the box with more memory and see what happens. I will follow up.

To be honest 67MB isn't so big. I can see how it's a problem if it fails, but in this day and age a couple hundred megs of peak memory isn't so much to ask for ;)

Ya, found the problem, the VM only has 6MB of mem available (out of 512MB) so, ya. Haha, I am upping it to have 1GB of memory. Should have checked that first. Carry on.

@Seldaek The micro instances have 590MB and by default no swap. For playing around this works fine, but as soon as some application needs a little bit more it completely breaks. So as mentioned earlier: Creating a swap catches this :) It only takes 10, or 20 MB more.

https://github.com/composer/composer/issues/945#issuecomment-8552757

@KingCrung is right. Just added swap to my EC2 micro instance as described here.

Now updating dependencies works like a charm.

@andremaha Perfect! Thank you!! :)

I'm also getting this problem. 1GB Vagrant on a 4GB Macbook Air. Happens even when I'm limiting an update to a specific vendor.

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:1033
Stack trace:

0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///usr/loc...', 1033, Array)

1 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(1033): proc_open('stty -a | grep ...', Array, NULL, NULL, NULL, Array)

2 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(911): Symfony\Component\Console\Application->getSttyColumns()

3 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(876): Symfony\Component\Console\Application->getTerminalDimensions()

4 phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php(810): Symfony\Component\Console\Application->getTerminalWidth()

Can solve it by vagrant halt && vagrant up && vagrant ssh, then running again.

Memory usage: 102.39MB (peak: 427.97MB), time: 104.79s

This solved my problem http://cloudstory.in/2012/02/adding-swap-space-to-amazon-ec2-linux-micro-instance-to-increase-the-performance/

@adamsmeat thanks! I use your solution for my DO instance

@adamsmeat - I can confirm on a stock loaded Ubuntu 12.04 512MB Digital Ocean machine that your solution is what was needed. Symfony2 is now installed and working as desired.

@adamsmeat that saved my life, just added 512MB swap space on my EC2 micro instance and the problem is solved.

我也遇到这样的问题，是使用vagrant box的环境，初始的内存为512M，增加到2048G后问题解决了。

encountered this problem using Digital Ocean 512MB slice...had to https://github.com/composer/composer/issues/945#issuecomment-8552757

same here @prodev42

I tried copying composer.lock unto the live server and works. with the command

php composer.phar --verbose install

@paparts Sounds like you don't versionize the composer.lock? As a rule of thumb: For applications versionize it, for libraries, don't. You shouldn't run update on a live system, because it is quite likely, that sooner or later a package comes in, that breaks your application, without that you've tested it locally. The composer.lock and composer.phar install ensures, that exactly that packages in that versions are installed, that you've development your application against.

I didn't notice that the framework I was using has listed the composer.lock on the ignore list. Thanks for pointing that out.

Had the issue today with EC2 micro instance. Increasing PHP memory_limit to 512M fixed it.

would that be a good thing to do? In digital ocean memory is only 512mb & putting PHP to consume up to such memory would probably dos your own VM.

oh, not at all. No need to mention it's not a production server.

I was installing a package that required symfony/event-dispatcher, so now I can't install a single package anymore due to the error above :S

Got this when I enabled opcache.enable_cli in php cli ini

@younes0 Thats pretty vague description. Did you read the whole discussion here? Usually it's because you ran out of memory without swap enabled usually within a pretty small cloud-instance, or VM.

@KingCrunch in my case, it wasn't related to insufficient memory, I got the error described by @yooper when I tried to install composer packages with the opcache.enable_cli php option set to On (VM or not)

Same error.

I have a digitalocean droplet with 1Gb RAM.

When I start php composer.phar update it eats all available RAM then throws an exception.

In my cli/php.ini I have memory_limit = -1.

If the solution is to upgrade to a droplet with a bigger RAM just for composer, I will do php composer.phar update on my local machine and then upload the files to my vps.

Just include composer.lock

@paparts Thank you, it works.

I do php composer.phar update on local machine then upload composer.lock to VPS and do php composer.phar install

@moldcraft The other solution is described somewhere above: Just create a swap-memory, that is pretty slow, but at least it prevents you from OOM errors.

@KingCrunch The other solution is described somewhere above

It will be nice if @yooper will update the issue description with found solutions

ProTip: the swap trick also works for local VirtualBox VMs running with Vagrant.

I try to insert using ajax,but that's not working,error is:uncaught exception: out of memory..
anything idea for this..

@sivagurupr I don't know, what you are talking about, but I've the feeling, that it is not related to this issue. Composer (CLI) doesn't have any ajax-capabilities :confused: However, at the end and after reading the comments "out of memory" should be self-explaining :wink:

Anything mistake in this code....

On Thu, Mar 12, 2015 at 4:08 PM, Sebastian Krebs [email protected]
wrote:

@sivagurupr https://github.com/sivagurupr I don't know, what you are
talking about, but I've the feeling, that it is not related to this issue.
Composer (CLI) doesn't have any ajax-capabilities [image: :confused:]
However, at the end and after reading the comments "out of memory" should
be self-explaining [image: :wink:]

—
Reply to this email directly or view it on GitHub
https://github.com/composer/composer/issues/945#issuecomment-78456750.

I ran ran into this issue when installing http://github.com/sabre/xml on a Vagrant machine. However I managed to fix it by enabling swapping using the example above.

I have the same error but with a large instance: 4gb RAM and 4gb swap. The free RAM is never exhausted, let alone the available/cached RAM, and the swap isn't touched!

It's the first time running composer update on this new machine, CentOS/CloudLinux 7.1.

Any ideas? Please?

I had the same error running in my Vagrant Box. I had 2gb of ram when I got the error. I extended the ram to 4gb and it worked. But, still it's weird that it needs so much ram.

I ran into this problem again and adding the composer.lock didn't work. But instead I tried to use swap space instead of extending much memory. An article on digitalocean is quite nifty https://www.digitalocean.com/community/tutorials/how-to-configure-virtual-memory-swap-file-on-a-vps

I also encountered the problem:

PHP Warning:  proc_open(): fork failed - Cannot allocate memory in phar:///home/...../sculpin.phar/vendor/symfony/console/Symfony/Component/Console/Application.php on line 974

My memory_limit is set to -1

my free output:

             total       used       free     shared    buffers     cached
Mem:          1992       1331        660        122          8        217
-/+ buffers/cache:       1105        886
Swap:          255        237         18

I was also having this issue but increasing the PHP memory_limit solved the problem.

me too

Was running into the same issue with memory_limit set to -1. The only thing that worked for me was reloading my machine.

How To Add Swap on Ubuntu 14.04
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04

This article helped me for 512M RAM instance.

[Solved] If you are running this in virtual machine, Stop the virtual machine either by vagrant halt command or by graceful stop.

Change RAM size as per your application, In my case i updated memory to 1024MB.
default it was 256MB;

i.e it worked

Stop mysql httpd or nginx service and run again

Run composer

And restart services

HI @sergiohermes

This only works, when nginx and/or mysql coincidentally consumes that much memory, that composer misses. Also stopping essential services is probably not an option in most cases. You should really invest in memory, either physically, or in form of a swap partition/file. It's all already documented in this thread.

I understand, anyway it was a way without having to swap.
The most appropriate but is to create a swap. Without a doubt.
Taking a look found for "centos" an interesting reference.

https://www.digitalocean.com/community/tutorials/additional-recommended-steps-for-new-centos-7-servers

I believe will add this thread.

Oh,I use swap solve it,thanks

You can avoid this either by increasing the memory size from php.ini file, which is a wrong option. Better delete the cache and rebuild the packages.

Delete composer cache: `sudo rm -R ~/.composer`
Delete vendor folder: `sudo rm -R vendor`
Rebuild the vendor packages: `composer update`

Or, I can be done by:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1

@mohitg-bs I guess you mixed something up

• Removing files doesn't free up RAM
• It's not about PHPs memory_limit, but the (virtual) memory from the entire system. There is no ini setting, that can create you RAM.

I solved the same problem in Vagrant.

I easily Increased Memory on Vagrant Virtual Machine http://www.josheaton.org/increase-memory-vagrant-virtual-machine/
then, I increased the value of memory_limit
and delete composer cache: sudo rm -R ~/.composer
and finally vagrant reload.

I had the same problem on a Virtual Box running through Vagrant.
Fixed by increasing VBox ram.

Config change from vb.memory = 512 to vb.memory = 1024

I have added swap memory and it solved my issue.

You ran out of swap memory, try this

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1

To add a swap file:

Determine the size of the new swap file in megabytes and multiply by 1024 to determine the number of blocks. For example, the block size of a 64 MB swap file is 65536.
At a shell prompt as root, type the following command with count being equal to the desired block size:
dd if=/dev/zero of=/swapfile bs=1024 count=65536
Setup the swap file with the command:
mkswap /swapfile
To enable the swap file immediately but not automatically at boot time:
swapon /swapfile
To enable it at boot time, edit /etc/fstab to include the following entry:
/swapfile swap swap defaults 0 0
The next time the system boots, it enables the new swap file.

After adding the new swap file and enabling it, verify it is enabled by viewing the output of the command cat /proc/swaps or free.

thank you!

Tips - if adding swap doesn't solve the composer out of memory/couldn't allocate error:

• Restart your machine after adding swap. I found composer error didn't go away after adding 8G of swap. But after restarting it worked.
• I also shut down another VM I was running and closed Chrome with too many tabs

(I'm using composer in a development environment on macOS X Sierra 10.12.4 with 16Gb RAM).

Has this been resolved? I have updated the Composer globally. In addition, I created a 1GB swap space per @gillera235 suggestion. I still get the same error. What can I do to troubleshoot it?

If it helps, I am using a free-tier micro EC2 instance.

push the composer.lock file on your server and do

composer --verbose install

this way it didn't take much memory and was superfast to install the updated packges according to versions in the composer.lock file.

it happens when you have less memory
try these steps
1)service mysql stop
2) run your comment
3)service mysql start

@sagarshah16 What happens if I don't have a mysql service?

try to find which one of your running services takes more memory space. if it is not mysql.

yeah ig update composer should solve the problem, sadly i update via git bash. It always throw same error to update. So to windows users just make sure use cmd.exe.

Hit the error earlier. Was on Ubuntu 16.04 on a EC2 micro instance.
Solved by adding a 1G swap file.

Just followed this link and resolved the issue.

https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-16-04

$ apt install swapspace 

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="16.04.3 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.3 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

Reference:
http://manpages.ubuntu.com/manpages/xenial/man8/swapspace.8.html

Thank you Jeroen T. Vermeulen

Enthusiasm is the light of knowledge. Unknown author.

O estusiasmo é luz do conhecimento. Autor desconhecido.

This issue can be exacerbated by not having memory over-commit enabled. Forking is massively inefficient without memory over-commit. Essentially when you fork, you double the committed memory usage of your current process by creating another identical process. Much of this memory is shared between the parent and child processes, but is copy-on-write, so any writes will cause the shared memory to get copied. When over-commit is enabled, your system allows this duplicated shared memory, but if you write to the shared memory, you might not have enough physical RAM to handle the copy. With over-commit disabled, your system won't allow you to allocate the memory in the first place.

Getting this error with 1.4GIG available...

$ free -m; composer require --dev phpro/grumphp
              total        used        free      shared  buff/cache   available
Mem:           2000         416        1277          21         305        1405
Swap:             0           0           0
Using version ^0.14.1 for phpro/grumphp
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 12 installs, 0 updates, 0 removals
  - Installing symfony/dependency-injection (v3.4.11): The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details


  [ErrorException]                                   
  proc_open(): fork failed - Cannot allocate memory

A fix for this problem is to add swap (i.e. paging) space to the instance.

Paging works by creating an area on your hard drive and using it for extra memory, this memory is much slower than normal memory however much more of it is available.

To add this extra space to your instance you type:

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo chmod 600 /var/swap.1
sudo /sbin/swapon /var/swap.1

If you need more than 1024 then change that to something higher.

To enable it by default after reboot, add this line to /etc/fstab:

/var/swap.1 swap swap defaults 0 0

@dhorrigan ouch according to the stack trace it looks like the fatal error was triggered while rendering an exception (since that uses proc_open to check for your terminal width). Looks like it's not a php memory limit but rather the machine's memory that ran out, so I would suggest clearing other things, and running it with install instead of update if you can run update somewhere else that has more memory. install from lock file uses very little memory.

Thanks so much, Instead of running composer update i did composer install. Which fixed it!

Its better to than having to increase memory size in php.ini or increasing instance memory itself.

Turning the swap on resolved my problem.

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1

How many of you will post something what was written in this thread? @jemerocay, have you read the topic? The same is posted ~10 messages above.

Contributors: close this, please.