Composer update php fatal error allowed memory size of

• General
• Package not found
• Package is not updating to the expected version
• Dependencies on the root package
• Network timeout issues, curl error
• Package not found in a Jenkins-build
• I have a dependency which contains a «repositories» definition in its composer.json, but it seems to be ignored.
• I have locked a dependency to a specific commit but get unexpected results.
• Need to override a package version
• Figuring out where a config value came from
• Memory limit errors
• Xdebug impact on Composer
• «The system cannot find the path specified» (Windows)
• API rate limit and OAuth tokens
• proc_open(): fork failed errors
• proc_open(): failed to open stream errors (Windows)
• Degraded Mode
• Operation timed out (IPv6 issues)
• Composer hangs with SSH ControlMaster
• Zip archives are not unpacked correctly.
• Disabling the pool optimizer

This is a list of common pitfalls on using Composer, and how to avoid them.

General#

1. When facing any kind of problems using Composer, be sure to work with the
   latest version. See self-update for details.

2. Before asking anyone, run composer diagnose to check
   for common problems. If it all checks out, proceed to the next steps.

3. Make sure you have no problems with your setup by running the installer’s
   checks via curl -sS https://getcomposer.org/installer | php -- --check.

4. Try clearing Composer’s cache by running composer clear-cache.

5. Ensure you’re installing vendors straight from your composer.json via
   rm -rf vendor && composer update -v when troubleshooting, excluding any
   possible interferences with existing vendor installations or composer.lock
   entries.

Package not found#

1. Double-check you don’t have typos in your composer.json or repository
   branches and tag names.

2. Be sure to set the right
   minimum-stability. To get started or be
   sure this is no issue, set minimum-stability to «dev».

3. Packages not coming from Packagist should
   always be defined in the root package (the package depending on all
   vendors).

4. Use the same vendor and package name throughout all branches and tags of
   your repository, especially when maintaining a third party fork and using
   replace.

5. If you are updating to a recently published version of a package, be aware that
   Packagist has a delay of up to 1 minute before new packages are visible to Composer.

6. If you are updating a single package, it may depend on newer versions itself.
   In this case add the --with-dependencies argument or add all dependencies which
   need an update to the command.

Package is not updating to the expected version#

Try running php composer.phar why-not [package-name] [expected-version].

Dependencies on the root package#

When your root package depends on a package which ends up depending (directly or
indirectly) back on the root package itself, issues can occur in two cases:

1. During development, if you are on a branch like dev-main and the branch has no
   branch-alias defined, and the dependency on the root package
   requires version ^2.0 for example, the dev-main version will not satisfy it.
   The best solution here is to make sure you first define a branch alias.

2. In CI (Continuous Integration) runs, the problem might be that Composer is not able
   to detect the version of the root package properly. If it is a git clone it is
   generally alright and Composer will detect the version of the current branch,
   but some CIs do shallow clones so that process can fail when testing pull requests
   and feature branches. In these cases the branch alias may then not be recognized.
   The best solution is to define the version you are on via an environment variable
   called COMPOSER_ROOT_VERSION. You set it to dev-main for example to define
   the root package’s version as dev-main.
   Use for example: COMPOSER_ROOT_VERSION=dev-main composer install to export
   the variable only for the call to composer, or you can define it globally in the
   CI env vars.

Network timeout issues, curl error#

If you see something along the lines of:

Failed to download * curl error 28 while downloading * Operation timed out after 300000 milliseconds

It means your network is probably so slow that a request took over 300seconds to complete. This is the
minimum timeout Composer will use, but you can increase it by increasing the default_socket_timeout
value in your php.ini to something higher.

Package not found in a Jenkins-build#

1. Check the «Package not found» item above.

2. The git-clone / checkout within Jenkins leaves the branch in a «detached HEAD»-state. As
   a result, Composer may not able to identify the version of the current checked out branch
   and may not be able to resolve a dependency on the root package.
   To solve this problem, you can use the «Additional Behaviours» -> «Check out to specific local
   branch» in your Git-settings for your Jenkins-job, where your «local branch» shall be the same
   branch as you are checking out. Using this, the checkout will not be in detached state any more
   and the dependency on the root package should become satisfied.

I have a dependency which contains a «repositories» definition in its composer.json, but it seems to be ignored.#

The repositories configuration property is defined as root-only. It is not inherited. You can read more about the reasons behind this in the «why can’t
Composer load repositories recursively?» article.
The simplest work-around to this limitation, is moving or duplicating the repositories definition into your root
composer.json.

I have locked a dependency to a specific commit but get unexpected results.#

While Composer supports locking dependencies to a specific commit using the #commit-ref syntax, there are certain
caveats that one should take into account. The most important one is documented, but
frequently overlooked:

Note: While this is convenient at times, it should not be how you use
packages in the long term because it comes with a technical limitation. The
composer.json metadata will still be read from the branch name you specify
before the hash. Because of that in some cases it will not be a practical
workaround, and you should always try to switch to tagged releases as soon
as you can.

There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.

Need to override a package version#

Let’s say your project depends on package A, which in turn depends on a specific
version of package B (say 0.1). But you need a different version of said package B (say 0.11).

You can fix this by aliasing version 0.11 to 0.1:

composer.json:

{
    "require": {
        "A": "0.2",
        "B": "0.11 as 0.1"
    }
}

See aliases for more information.

Figuring out where a config value came from#

Use php composer.phar config --list --source to see where each config value originated from.

Memory limit errors#

The first thing to do is to make sure you are running Composer 2, and if possible 2.2.0 or above.

Composer 1 used much more memory and upgrading to the latest version will give you much better and faster results.

Composer may sometimes fail on some commands with this message:

PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>

In this case, the PHP memory_limit should be increased.

Note: Composer internally increases the memory_limit to 1.5G.

To get the current memory_limit value, run:

php -r "echo ini_get('memory_limit').PHP_EOL;"

Try increasing the limit in your php.ini file (ex. /etc/php5/cli/php.ini for
Debian-like systems):

; Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1

Composer also respects a memory limit defined by the COMPOSER_MEMORY_LIMIT environment variable:

COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>

Or, you can increase the limit with a command-line argument:

php -d memory_limit=-1 composer.phar <...>

This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the documentation of the fork bomb feature on the cPanel site.

Xdebug impact on Composer#

To improve performance when the Xdebug extension is enabled, Composer automatically restarts PHP without it.
You can override this behavior by using an environment variable: COMPOSER_ALLOW_XDEBUG=1.

Composer will always show a warning if Xdebug is being used, but you can override this with an environment variable:
COMPOSER_DISABLE_XDEBUG_WARN=1. If you see this warning unexpectedly, then the restart process has failed:
please report this issue.

«The system cannot find the path specified» (Windows)#

1. Open regedit.
2. Search for an AutoRun key inside HKEY_LOCAL_MACHINESoftwareMicrosoftCommand Processor,
   HKEY_CURRENT_USERSoftwareMicrosoftCommand Processor
   or HKEY_LOCAL_MACHINESoftwareWow6432NodeMicrosoftCommand Processor.
3. Check if it contains any path to a non-existent file, if it’s the case, remove them.

API rate limit and OAuth tokens#

Because of GitHub’s rate limits on their API it can happen that Composer prompts
for authentication asking your username and password so it can go ahead with its work.

If you would prefer not to provide your GitHub credentials to Composer you can
manually create a token using the procedure documented here.

Now Composer should install/update without asking for authentication.

proc_open(): fork failed errors#

If Composer shows proc_open() fork failed on some commands:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar

This could be happening because the VPS runs out of memory and has no Swap space enabled.

free -m

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

To enable the swap you can use for example:

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

You can make a permanent swap file following this tutorial.

proc_open(): failed to open stream errors (Windows)#

If Composer shows proc_open(NUL) errors on Windows:

proc_open(NUL): failed to open stream: No such file or directory

This could be happening because you are working in a OneDrive directory and
using a version of PHP that does not support the file system semantics of this
service. The issue was fixed in PHP 7.2.23 and 7.3.10.

Alternatively it could be because the Windows Null Service is not enabled. For
more information, see this issue.

Degraded Mode#

Due to some intermittent issues on Travis and other systems, we introduced a
degraded network mode which helps Composer finish successfully but disables
a few optimizations. This is enabled automatically when an issue is first
detected. If you see this issue sporadically you probably don’t have to worry
(a slow or overloaded network can also cause those time outs), but if it
appears repeatedly you might want to look at the options below to identify
and resolve it.

If you have been pointed to this page, you want to check a few things:

• If you are using ESET antivirus, go in «Advanced Settings» and disable «HTTP-scanner»
  under «web access protection»
• If you are using IPv6, try disabling it. If that solves your issues, get in touch
  with your ISP or server host, the problem is not at the Packagist level but in the
  routing rules between you and Packagist (i.e. the internet at large). The best way to get
  these fixed is to raise awareness to the network engineers that have the power to fix it.
  Take a look at the next section for IPv6 workarounds.
• If none of the above helped, please report the error.

Operation timed out (IPv6 issues)#

You may run into errors if IPv6 is not configured correctly. A common error is:

The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out

We recommend you fix your IPv6 setup. If that is not possible, you can try the
following workarounds:

Workaround Linux:

On linux, it seems that running this command helps to make ipv4 traffic have a
higher priority than ipv6, which is a better alternative than disabling ipv6 entirely:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

Workaround Windows:

On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).

Workaround Mac OS X:

Get name of your network device:

networksetup -listallnetworkservices

Disable IPv6 on that device (in this case «Wi-Fi»):

networksetup -setv6off Wi-Fi

Run Composer …

You can enable IPv6 again with:

networksetup -setv6automatic Wi-Fi

That said, if this fixes your problem, please talk to your ISP about it to
try to resolve the routing errors. That’s the best way to get things resolved
for everyone.

Composer hangs with SSH ControlMaster#

When you try to install packages from a Git repository and you use the ControlMaster
setting for your SSH connection, Composer might hang endlessly and you see a sh
process in the defunct state in your process list.

The reason for this is a SSH Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1988

As a workaround, open a SSH connection to your Git host before running Composer:

ssh -t git@mygitserver.tld
php composer.phar update

See also https://github.com/composer/composer/issues/4180 for more information.

Zip archives are not unpacked correctly.#

Composer can unpack zipballs using either a system-provided unzip or 7z (7-Zip) utility, or PHP’s
native ZipArchive class. On OSes where ZIP files can contain permissions and symlinks, we recommend
installing unzip or 7z as these features are not supported by ZipArchive.

Disabling the pool optimizer#

In Composer, the Pool class contains all the packages that are relevant for the dependency
resolving process. That is what is used to generate all the rules which are then
passed on to the dependency solver.
In order to improve performance, Composer tries to optimize this Pool by removing useless
package information early on.

If all goes well, you should never notice any issues with it but in case you run into
an unexpected result such as an unresolvable set of dependencies or conflicts where you
think Composer is wrong, you might want to disable the optimizer by using the environment
variable COMPOSER_POOL_OPTIMIZER and run the update again like so:

COMPOSER_POOL_OPTIMIZER=0 php composer.phar update

Now double check if the result is still the same. It will take significantly longer and use
a lot more memory to run the dependency resolving process.

If the result is different, you likely hit a problem in the pool optimizer.
Please report this issue so it can be fixed.

Found a typo? Something is wrong in this documentation?
Fork and edit it!

Hi,

I am using composer on my Laravel 6 project. However, somehow I always run into the problem is «Allowed memory size of 1610612736 bytes exhausted». I don’t know why but since a few days I have this problem and I don’t know why or where it does come from.

The curios thing is that I get exactly the same error on my development server. That means it must has to do something with the Laravel project itself. Because as I said, on my Mac as well as on my development server I get the exact same output with exact the same config and project.

The only workaround is php -d memory_limit=-1 composer update. But I cannot do this on my server because I am not the admin of the server and have a limited RAM usage. So, I do want to know what is causing this problem and how I can solve this.

Do you need any more information then those below?
I appreciate any kind of help!

Kind regards and thank you!

My composer.json:

{
    "name": "laravel/laravel",
    "type": "project",
    "description": "The Laravel Framework.",
    "keywords": [
        "framework",
        "laravel"
    ],
    "license": "MIT",
    "repositories": [
        {
            "type": "composer",
            "url": "https://nova.laravel.com"
        }
    ],
    "require": {
        "php": "^7.2",
        "components/jquery": "^3.4",
        "cybercog/laravel-nova-ban": "^1.1",
        "emilianotisato/nova-tinymce": "^1.1",
        "fideloper/proxy": "^4.0",
        "glorand/laravel-model-settings": "^3.5",
        "inspheric/nova-indicator-field": "^1.43",
        "kabbouchi/nova-logs-tool": "^0.2.0",
        "laravel/framework": "^6.2",
        "laravel/nova": "~2.0",
        "laravel/socialite": "^4.4",
        "laravel/telescope": "^3.0",
        "laravel/tinker": "^1.0",
        "laravel/ui": "^1.1",
        "laravelcollective/html": "^6.1",
        "llaski/nova-scheduled-jobs": "^3.0",
        "mad-web/nova-telescope-link": "^3.0",
        "orangehill/iseed": "^2.6",
        "paquettg/php-html-parser": "^2.1",
        "pdewit/nova-external-url": "^1.0",
        "phpunit/php-code-coverage": "^9.1",
        "phpunit/phpunit": "^9.2",
        "spatie/laravel-honeypot": "^1.4",
        "spatie/laravel-medialibrary": "^7.19",
        "spatie/laravel-permission": "^3.2",
        "twbs/bootstrap": "^4.3",
        "vyuldashev/nova-permission": "^2.9",
        "yoeunes/toastr": "^1.2"
    },
    "require-dev": {
        "barryvdh/laravel-debugbar": "^3.2",
        "barryvdh/laravel-ide-helper": "^2.6",
        "brianium/paratest": "^4.1",
        "facade/ignition": "^1.4",
        "fzaninotto/faker": "^1.4",
        "mockery/mockery": "^1.0",
        "nunomaduro/collision": "^3.0"
    },
    "config": {
        "optimize-autoloader": true,
        "preferred-install": "dist",
        "sort-packages": true
    },
    "extra": {
        "laravel": {
            "dont-discover": []
        }
    },
    "autoload": {
        "psr-4": {
            "App\": "app/"
        },
        "classmap": [
            "database/seeds",
            "database/factories"
        ],
        "files": [
            "app/Helpers/helper.php",
            "app/Helpers/commentsHelper.php"
        ]
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\": "tests/"
        }
    },
    "minimum-stability": "dev",
    "prefer-stable": true,
    "scripts": {
        "post-autoload-dump": [
            "Illuminate\Foundation\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ],
        "post-root-package-install": [
            "@php -r "file_exists('.env') || copy('.env.example', '.env');""
        ],
        "post-create-project-cmd": [
            "@php artisan key:generate --ansi"
        ],
        "post-update-cmd": [
            "Illuminate\Foundation\ComposerScripts::postUpdate",
            "@php artisan ide-helper:generate",
            "@php artisan ide-helper:meta"
        ]
    }
}

Output of composer diagnose:

Checking composer.json: OK
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.10.10
PHP version: 7.3.18
PHP binary path: /usr/local/Cellar/php@7.3/7.3.18_1/bin/php
OpenSSL version: OpenSSL 1.1.1g  21 Apr 2020

When I run this command:

(Basically any commands where I install, remove or update packages)

composer update
composer install
...
...

I get the following output:

PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.10.7/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.10.7/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

Anyone who has used Composer for more than a hot second has likely run into the dreaded “out of memory” error. There are a few ways to fix this, including a permanent fix. Let me show you how!

The Problem

The error looks something like this:

PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.9.3/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.9.3/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

This just happened to me while running the following command:

$ composer create-project acquia/lightning-project MY_PROJECT

Remember that Composer is using PHP to execute, so in this case the problem is that my computer most likely doesn’t have enough memory to allocate to the PHP process.

Checking PHP Memory Limit

All you have to do to check your PHP Memory Limit is:

1. figure out which php.ini file your computer is currently using (if you followed my guide on setting up a new Macbook and/or are using Homebrew, you likely aren’t using the stock one that shipped with your computer). Run this: $ php —ini

Configuration File (php.ini) Path: /usr/local/etc/php/7.3

Loaded Configuration File:         /usr/local/etc/php/7.3/php.ini

Scan for additional .ini files in: /usr/local/etc/php/7.3/conf.d

Additional .ini files parsed:      /usr/local/etc/php/7.3/conf.d/ext-opcache.ini

You’re interested in the “loaded” configuration file (so for me, it’s in /usr/local/etc/php/7.3/php.ini).

2. Using your preferred editing method, open up that php.ini file and find the memory_limit setting. This is what I found:

; Maximum amount of memory a script may consume (128MB)

; http://php.net/memory-limit

memory_limit = 128MB

That’s not NEARLY enough!

Upping Your PHP Memory Limit

1. Using the same steps as above, we’ll want to edit the php.ini file.

Update the default memory_limit. I upped mine to 2048MB (2GB)

; Maximum amount of memory a script may consume (128MB)

; http://php.net/memory-limit

memory_limit = 2048MB

Note: you may have to up it even higher or set it to -1 (for unlimited, which is what the Composer docs suggest).

2. Restart your apache server and terminal so the change will take effect.

sudo apachectl restart

3. Run your composer command again.

A Temporary Fix

You can also fix this on a “case by case” basis if you so desire (or your machine is locked down and you can’t change your php.ini file without an administrator’s assistance) by running commands like this:

$ COMPOSER_MEMORY_LIMIT=-1 composer <command>

This will ensure that there is no PHP memory limit imposed on the current command being run. It’s not a long term fix though, so if you don’t up the memory limit permanently you will likely have to do this over and over again!

Related Content

A recent attempt to run an update composer (regular activity for many of us), I had a memory limit issue.  This was surprising because the memory setting via Plesk is set to 2G.  Yet through Terminal it was showing only 128MB.  What gives??  

The error I was seeing:

PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/lib64/plesk-9.0/composer.phar/src/Composer/DependencyResolver/Pool.php on line 339

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/lib64/plesk-9.0/composer.phar/src/Composer/DependencyResolver/Pool.php on line 339

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

or

PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/psa/var/modules/composer/composer.phar/src/Composer/DependencyResolver/Solver.php on line 223

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/psa/var/modules/composer/composer.phar/src/Composer/DependencyResolver/Solver.php on line 223

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

I have had both of these errors (at different times).  However, the solution for me was the same in both instances.

How to investigate this error

In this instance, the PHP memory_limit was being applied to the wrong PHP version.  As noted above the respective PHP version is showing 128MB and needs to be increased to something bigger.  How do you get the current memory_limit value?  By running the following command through shell program like Terminal:

php -r "echo ini_get('memory_limit').PHP_EOL;"

This will confirm the current memory_limit as noted in the error being

128M

Even though Plesk had a different memory limit, composer wasn’t utilising that, but rather the setting in the php.ini file.  Subsequently, try increasing the limit in your php.ini file.  For me the php.ini is located in /etc directory.  However, it might not be in the etc directory or it is, yet it is not the php.ini file being use.  

How to find the php.ini in use?  In shell run the command:

php -i

This will output the phpinfo() data… displaying something like

PHP Version => 7.3.25

Build Date => Nov 26 2020 20:28:14

Configure Command =>  './configure'  '--docdir=/opt/plesk...'

Do a search for php.ini to see the result being something like:

Configuration File (php.ini) Path => /etc

or

Configuration File (php.ini) Path => /opt/plesk/php/7.3/etc

Loaded Configuration File => /opt/plesk/php/7.3/etc/php.ini

Resolving the error

Now that you know the php.ini file being used (for me it was /opt/plesk/php/7.3/etc), you can edit the php.ini file through using the vi command either going to the directory path and using:

vi php.ini

or 

vi /opt/plesk/php/7.3/etc/php.ini

While in edit mode, perform a quick search rather than scrolling through the file using /{search term}.  In this instance search for memory_limit, subsequently the find entry will be

/memory_limit

This will take you to the location of memory_limit, looking something like

; Maximum amount of memory a script may consume (128MB)
; http://www.php.net/manual/en/ini.core.php#ini.memory-limit
memory_limit = 128M

Use -1 for unlimited or define an explicit value like 2G (remember to enter edit / insert mode you will need to press i).  Change the memory_limit to something bigger.  For me I changed it to 2G.

memory_limit = 2G

Save and close vim, press [Esc] key and type :wq!

[esc]:wq!

Done.

Always a good idea to run through the above script again and test the memory_limit value has been updated and now reflects your new value rather than 128MB.

How come I changed the memory_limit from 128M to 2G?

At face value, yes this seems quite a significant jump.  A clue indicating that you need to have a decent jump is in the error itself.  Actually there are two areas of css:

1. Allowed memory size of 1610612736 bytes exhausted
2. Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors

Allowed memory size 1610612736

Converting 1610612736 bytes to GB is 1.61G.  Therefore the current allocation of 128M is severely inadequate.

Check memory-limit-errors message

In the last line of the error message there is a reference to a URL on the getcomposer.org site.  If you go to this site you will read

Composer may sometimes fail on some commands with this message:

PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>

In this case, the PHP memory_limit should be increased.  Note: Composer internally increases the memory_limit to 1.5G.

The site also outlines setting an unlimited amount, which can be achieved by entering -1.  Personally, I prefer to set a finite allocation and test the allocation.  If you want to monitor how hungry Composer is you can open a second window and log in to the server.  This while the composer command is running, in the second window run the command

free -m

This will output how the current memory resources are being allocated.

Error — E212: Can’t open file for writing

On a recent change to the memory_limit, I had an E212: Can’t open file for writing error.  This was a quick resolve as I had logged in to the server as a user other than root.  The memory_limit change required me to be a root user.  Once I had another connection through shell as a root user the update was seamless.

Quick snapshot of your memory size by the error

If you aren’t sure what your PHP memory limit is set to, it’s helpfully included in the error message. The size is reported in bytes:

PHP: Fatal Error: Allowed Memory Size of 8388608 Bytes Exhausted — 8 MB
PHP: Fatal Error: Allowed Memory Size of 16777216 Bytes Exhausted — 16 MB
PHP: Fatal Error: Allowed Memory Size of 33554432 Bytes Exhausted — 32 MB
PHP: Fatal Error: Allowed Memory Size of 67108864 Bytes Exhausted — 64 MB
PHP: Fatal Error: Allowed Memory Size of 134217728 Bytes Exhausted — 128 MB
PHP: Fatal Error: Allowed Memory Size of 268435456 Bytes Exhausted — 256 MB
PHP: Fatal Error: Allowed Memory Size of 536870912 Bytes Exhausted — 512 MB
PHP: Fatal Error: Allowed Memory Size of 1073741824 Bytes Exhausted — 1 GB