Related
Executed this command, but the help menu for composer is getting displayed
php -d memory_limit=-1 composer
this is the in the directory where the composer file is located (the bin directory). tried with composer.phar, says file does not exist.
please help. thank you
Based on the document, you should be able to add a composer command in the <...>
php -d memory_limit=-1 composer <...>
So, for things like
php -d memory_limit=-1 composer require apackage
php -d memory_limit=-1 composer update
That means to run the composer command with memory_limit = -1.
I need to run composer update at my hosting so I log in with ssh and try to run the following command inside /www folder where I have Laravel and composer installation:
composer update
I get this error:
I'm in contact with my hosting provider, they told me to run the command:
php -d memory_limit=512M composer update
I ran this command but I got: "Could not open file: composer"
What to do? What is the solution here?
Set it to use as much memory as it wants with:
COMPOSER_MEMORY_LIMIT=-1 composer update
When you run composer update, the OS will look into the configured paths and try to locate an executable file with that name.
When running php composer update, the composer string is treated as a parameter to PHP, which is not searched in any paths. You have to provide the full path in order to run it.
Running which composer will tell you where the OS finds the composer executable, and then you simply use the full path in the PHP command:
$>which composer
/usr/local/bin/composer
$>php -d memory_limit=512M /usr/local/bin/composer update
...
Note that 512MB might be too few. My perception is that it will happily take 1GB or more, depending on the number of dependencies you use and the variety of versions that you theoretically allow, i.e. if you allow Symfony ~2.3, then you make Composer deal with a lot more possible versions compared to using ~2.7.
Also note that running Composer on the production machine is not the best idea. You would have to have access to Github, maybe provide access credentials, have VCS tools installed, and you will easily break your site if any of the remote hosting servers is offline during your update. It is a better idea to use Composer on a deployment system that does all the preparation, and then moves all the files onto the production server.
Update
It's the year 2020 now, and the way Composer manages its memory has changed quite a bit. The most important thing is that Composer will increase the memory limit by itself if it encounters a limit set too low. This however immediately triggers the problem of running out of memory on machines that have too few memory installed. You can make Composer use less memory by setting the environment variable like COMPOSER_MEMORY_LIMIT=512M, but this will create problems if Composer would need more memory to correctly operate.
My main point remains true: Do not run Composer on machines that have too few memory installed. You potentially need 1.5 GB of free memory to be able to update everything.
The best solution for me is
COMPOSER_MEMORY_LIMIT=-1 composer require <package-name>
mentioned by #realtebo
I am facing problems with composer because it consumes all the available memory, and then, the process get killed ( actualy, the output message is "Killed")
So, I was looking for a solution to limit composer memory usage.
I tried ( from #Sven answers )
$ php -d memory_limit=512M /usr/local/bin/composer update
But it didn't work because
"Composer internally increases the memory_limit to 1.5G."
-> Thats from composer oficial website.
Then I found a command that works :
$ COMPOSER_MEMORY_LIMIT=512M php composer.phar update
Althought, in my case 512mb is not enough !
Source : https://www.agileana.com/blog/composer-memory-limit-troubleshooting/
I had to combine COMPOSER_MEMORY_LIMIT and memory_limit in the command line:
On Windows:
set COMPOSER_MEMORY_LIMIT=99999999999&& php -d memory_limit=-1 composer.phar update
On Linux:
export COMPOSER_MEMORY_LIMIT=99999999999 && php -d memory_limit=-1 composer.phar update
If there's enough memory composer would internally consume it and run without any problem. No need to specifically tell the composer to do it.
Have you tried to increase your swap memory, coz it worked for me. I increased the swap memory to 4096Mb (4GB) and now it all looks great to me.
first use "sudo free" to see available memory and swap memory. and configure swap as,
For Debian:
sudo fallocate -l 4G /swapfile
sudo dd if=/dev/zero of=/swapfile bs=4096k count=1048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
to make it permenant add this to /etc/fstab file, /swapfile swap swap defaults 0 0
For CentOS :
[root#myserver]:/# cd /var
[root#myserver]:/var# touch swap.img
[root#myserver]:/var# chmod 600 swap.img
[root#myserver]:/var# mkswap /var/swap.img
[root#myserver]:/var# dd if=/dev/zero of=/var/swap.img bs=4096k count=1000
[root#myserver]:/var# mkswap /var/swap.img
[root#myserver]:/var# swapon /var/swap.img
you can increase your swap memory by changin bs= 1024k or 2048k or 8096k
depending on your physical volume size.
use 'swapon' and swapoff commands to see the difference.
check 'swappiness' (60 should do good,)
cat /proc/sys/vm/swappiness
You can change the memory_limit value in your php.ini
Try increasing the limit in your php.ini file
Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1
Note: Composer internally increases the memory_limit to 1.5G.
Read the documentation getcomposer.org
I made this on Windows 10 and worked with me:
php -d memory_limit=-1 C:/ProgramData/ComposerSetup/bin/composer.phar update
You can change xx Value that you want
memory_limit=XX
On MAC OS High Siera I ran the below:
MacBook-Pro:asiu jack$ php --ini
Returned:
Configuration File (php.ini) Path: /usr/local/etc/php/7.4
Loaded Configuration File: /usr/local/etc/php/7.4/php.ini
Scan for additional .ini files in: /usr/local/etc/php/7.4/conf.d
Additional .ini files parsed: /usr/local/etc/php/7.4/conf.d/ext-
opcache.ini,
/usr/local/etc/php/7.4/conf.d/php-memory-limits.ini
All answers above are setting the loaded config which does update, but notice additional .ini files parsed has php-memory-limits.ini as a separate file. You have to update this file memeory limit as well. same way open in text editor and change to somehting like 2G. The output on memory limit failure should tell you how much memory it needs to run, just set it to higher than that or -1 for unlimited.
COMPOSER_MEMORY_LIMIT=-1 composer update --ignore-platform-reqs
This error can occur especially when you are updating large libraries or libraries with a lot of dependencies. Composer can be quite memory hungry.
Be sure that your composer itself is updated to the latest version:
php composer.phar --self-update
You can increase the memory limit for composer temporarily by adding the composer memory limit environment variable:
COMPOSER_MEMORY_LIMIT=128MB php composer.phar update
Use the format “128M” for megabyte or “2G” for gigabyte. You can use the value “-1” to ignore the memory limit completely.
Another way would be to increase the PHP memory limit:
php -d memory_limit=512M composer.phar update ...
<C:\>set COMPOSER_MEMORY_LIMIT=-1
<C:\>composer install exhausted/packages
For Laravel
Step 1. Open your terminal
step 2. cd into your laravel directory
step 3. Type the command which composer, in your laravel directory and note the directory in which composer resides.
step 4. run the command php -d memory_limit=-1 /opt/cpanel/bin/composer update (you can also run the code if it works for you)
(change /opt/cpanel/bin/composer to the directory path returned in step 3 )
Problem solved
How large is your aws server? If it only has 1gb of ram, setting the memory limit of 2gb in php.ini won't help.
If you can't/don't want to also increase the server side to get more RAM available, you can enable SWAP as well.
See here for how to enable swap. It enables 4gb, although I typically only do 1GB myself.
Source: Got from laracast site
I'm running Laravel 6 with Homestead and also ran into this problem. As suggested here in the other answers you can prefix COMPOSER_MEMORY_LIMIT=-1 to a single command and run the command normally. If you'd like to update your PHP config to always allow unlimited memory follow these steps.
vagrant up
vagrant ssh
php --version # 7.4
php --ini # Shows path to the php.ini file that's loaded
cd /etc/php/7.4/cli # your PHP version. Each PHP version has a folder
sudo vi php.ini
Add memory_limit=-1 to your php.ini file. If you're having trouble using Vim or making edits to the php.ini file check this answer about how to edit the php.ini file with Vim. The file should look something like this:
; Maximum amount of memory a script may consume
; http://php.net/memory-limit
memory_limit = -1
Note that this could eat up infinite amount of memory on your machine. Probably not a good idea for production lol. With Laravel Valet had to follow this article and update the memory value here:
sudo vi /usr/local/etc/php/7.4/conf.d/php-memory-limits.ini
Then restart the server with Valet:
valet restart
This answer was also helpful for changing the config with Laravel Valet on Mac so the changes take effect.
For those who use Laravel Homestead
Write this on Homestead.yaml
variables:
- key: COMPOSER_MEMORY_LIMIT
value: -1
In my case none of the answers helped. Finally it turned out, that changing to a 64 bit version of PHP (M$ Windows) fixed the problem immediately. I did not change any settings - it just worked.
Go to your php ini file
set memory_limit = -1
In Windows 10 (Git bash), i had to use this
php -d memory_limit=-1 C:\\composer\\composer.phar install
Its fixed in later composer versions.
On Windows I had to uninstall composer then download+install latest version https://getcomposer.org/download/
Now running composer update works!
First of all, try to update composer:
composer self-update
For some reason composer v1.0 doesn't works fine, in my case I had to update composer, after that I can execute:
composer update
In my case it needed higher permissions along with this memory limit increase.
sudo COMPOSER_MEMORY_LIMIT=2G php /opt/bitnami/php/bin/composer.phar update
When running composer diagnose, I get the following error :
The xdebug extension is loaded, this can slow down Composer a little.
Disabling it when using Composer is recommended.
How can I disable xdebug only when I'm running Composer?
Update: For Xdebug 3+:
As of Xdebug 3, it is possible to disable the Xdebug completely by setting the option xdebug.mode to off, or by setting the environment variable XDEBUG_MODE=off.
It is very easy to disable Xdebug just for composer, by aliasing composer.
alias composer='XDEBUG_MODE=off \composer'
OR
alias composer='php -dxdebug.mode=off $(where composer | fgrep -v composer: | head -1)'
You can add the alias to your $HOME/.bashrc to make it permanent.
Update: For Xdebug 1.3 - 3.0.0 :
The issue has been fixed in Composer 1.3. Update composer to the latest version by executing composer self-update, instead of trying the following workaround.
For Xdebug < 1.3
Here is my modification of #ezzatron's code. I have updated the script to detect ini files from phpinfo output.
#!/bin/sh
php_no_xdebug () {
temporaryPath="$(mktemp -t php.XXXX).ini"
# Using awk to ensure that files ending without newlines do not lead to configuration error
php -i | grep "\.ini" | grep -o -e '\(/[a-z0-9._-]\+\)\+\.ini' | grep -v xdebug | xargs awk 'FNR==1{print ""}1' | grep -v xdebug > "$temporaryPath"
php -n -c "$temporaryPath" "$#"
rm -f "$temporaryPath"
}
php_no_xdebug /usr/local/bin/composer.phar $#
# On MacOS with composer installed using brew, comment previous line
# Install jq by executing `brew install jq` and uncomment following line.
# php_no_xdebug /usr/local/Cellar/composer/`brew info --json=v1 composer | jq -r '.[0].installed[0].version'`/libexec/composer.phar $#
This command will disable the PHP5 Xdebug module for CLI (and thus composer) :
sudo php5dismod -s cli xdebug
It removes the xdebug.ini symlink from /etc/php5/cli/conf.d/
This was suggested on http://blog.lorenzbausch.de/2015/02/10/php-disable-xdebug-for-cli/
Note that for Ubuntu 16.04 you probably need to run it like this:
sudo phpdismod -s cli xdebug
I don’t think there is an option to configure PHP so it can load different configurations according to the targeted script. At least, not without duplicating .ini files...
However, you can add thoses options when running composer with php:
php -n -d extension=needed_ext.so composer.phar
-n will tell PHP to ignore any php.ini. This will prevent xdebug from loading for this very command.
-d options permits you to add any option you want (for exemple, activate needed_ext.so). You can use multiple -d options. Of course, this is optional, you might not need it.
Then you can create an alias, to make it sugary again.
A typical solution (because composer needs json):
php -n -d extension=json.so composer.phar
greg0ire > my solution, based on that:
#!/bin/bash
options=$(ls -1 /usr/lib64/php/modules| \
grep --invert-match xdebug| \
# remove problematic extensions
egrep --invert-match 'mysql|wddx|pgsql'| \
sed --expression 's/\(.*\)/ --define extension=\1/'| \
# join everything together back in one big line
tr --delete '\n'
)
# build the final command line
php --no-php-ini $options ~/bin/composer $*
alias composer=/path/to/bash/script.sh
It looks ugly (I tried and failed to do that with xargs), but works… I had to disable some extensions though, otherwise I get the following warnings:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mysqli.so' - /usr/lib64/php/modules/mysqli.so: undefined symbol: mysqlnd_connect in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_mysql.so' - /usr/lib64/php/modules/pdo_mysql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/pdo_pgsql.so' - /usr/lib64/php/modules/pdo_pgsql.so: undefined symbol: pdo_parse_params in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/wddx.so' - /usr/lib64/php/modules/wddx.so: undefined symbol: php_XML_SetUserData in Unknown on line 0
You can disable Xdebug setting an environment variable:
XDEBUG_MODE=off composer install
It's available using XDebug 3.
By creating an alias you'll suppress that composer xdebug error message.
Just add this line to your ~/.bash_aliases within your system and it should work flawlessly.
alias composer="php -n /usr/local/bin/composer"
Reload the shell to make the new alias composer available.
source ~/.bash_profile
USAGE:
$ composer --version
NOTE:
You don't necessarily need to use any other parameter.
Depending on your system you might have a .bashrc instead of .bash_profile.
UPDATE:
As #AlexanderKachkaev mention in the comments it's worth nothing to add the memory_limit as follows to avoid crashing im some situations:
alias composer="php -d memory_limit=-1 -n /usr/local/bin/composer"
I came up with an answer that works pretty well for OSX, and could probably be adapted for any PHP version that loads its extensions using individual .ini files in the "additional ini dir":
#!/bin/sh
function php-no-xdebug {
local temporaryPath="$(mktemp -t php-no-debug)"
find /opt/local/etc/$1/php.ini /opt/local/var/db/$1/*.ini ! -name xdebug.ini | xargs cat > "$temporaryPath"
php -n -c "$temporaryPath" "${#:2}"
rm -f "$temporaryPath"
}
alias composer="php-no-xdebug php56 ~/bin/composer"
I usually create a shell script per project, since every project has another PHP version. It's in a /bin/ directory next to composer.phar and composer.json and I run it as ./bin/composer in my project directory.
It looks like this (for php56)
#!/bin/sh
DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
COMPOSER_DISABLE_XDEBUG_WARN=1 /opt/local/bin/php56 \
-d xdebug.remote_enable=0 -d xdebug.profiler_enable=0 \
-d xdebug.default_enable=0 $DIR/../composer.phar "$#"
The -d options effectively disable xdebug. The COMPOSER_DISABLE_XDEBUG_WARN=1 part disables the warning composer issues.
Disabling the xdebug extension is preferred (see composer troubleshooting), but I personally like the simpler script.
Some timings on my machine:
2
Run with xdebug and ini-enabled: 1m33
Run with xdebug but ini-disabled: 0m19
Run without xdebug: 0m10
If you use PHPStorm, the latest release (2016.2) comes with a feature to enable XDebug for CLI scripts on-demand, which means you can simply turn off XDebug globally on your development machine. The IDE will enable it on the fly when it is needed by code inside your projects.
https://blog.jetbrains.com/phpstorm/2016/06/xdebug-on-demand-for-cli-php-scripts-in-phpstorm-2016-2-eap/
PhpStorm 2016.2 introduces Xdebug On Demand mode where you can disable Xdebug for your global PHP install, and PhpStorm will only enable it when it needs to — when you’re debugging your scripts, or when you need code coverage reports.
You need to edit your PHP Interpreters preferences to include the path to XDebug, as described in the linked article.
To me this seems like the perfect solution, as I only usually want XDebug while I'm in the IDE.
However XDebug does have other potential uses when you are "offline" e.g. extended stack dumps in error logs, which you would lose by turning it off globally. Of course you shouldn't have XDebug enabled on production, so this would be limited to use cases like beta-testing or automated-testing CLI scripts in development.
Rather than muddle with temporarily enabling or disabling the PHP module, when you might have concurrent processes using PHP (for example as part of a CI pipeline), you can tell PHP to point at a different module loading directory.
While this is similar to some of the solutions mentioned above, this solves a few edge cases, which is very useful when being used by Jenkins or other CI runner which runs tests on the same machine concurrently.
The easiest way to do this is to use the environment variable PHP_INI_SCAN_DIR
Using this in a script or build task is easy:
export PHP_INI_SCAN_DIR=/etc/php.d.noxdebug
php composer install
Of course you would want to prepare /etc/php.d.noxdebug first, doing something like:
mkdir /etc/php.d.noxdebug
cp /etc/php.d/* /etc/php.d.noxdebug
rm /etc/php.d.noxdebug/xdebug.ini
This means you have an environment similar to the old php environment, with only one module missing. Meaning you don't need to worry about needing to load the phar/json modules as you would with the php -n solution.
Direct manipulation of PHP config
Here's my contribution based on a Homebrew-installed PHP installation on Mac OS X.
It's a shell-script wrapper, designed to be saved as an executable file at /usr/local/bin/composer, with the Composer binary at /usr/local/bin/composer.phar:
#!/bin/sh
sed -i '' -e 's:zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
/usr/local/bin/php /usr/local/bin/composer.phar "$#"
sed -i '' -e 's:;zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":zend_extension="/usr/local/opt/php55-xdebug/xdebug.so":' /usr/local/etc/php/5.5/conf.d/ext-xdebug.ini
Theory of Operation
The wrapper script:
uses sed to temporarily modify the configuration file, disabling Xdebug (line 2)
executes Composer, passing through args to the command (line 3)
uses sed to restore the configuration file, re-enabling Xdebug (line 4)
The script is coupled to an OS X/Homebrew installation of PHP 5.5. The paths should be adjusted to work with other PHP versions and other operating systems' and package managers' directory layouts. Note also that some versions of sed do not need the empty-string argument following the -i option.
Caveat Utilitor
The script is straightforward, in that it works directly on the main PHP configuration files, however this is also a drawback: Xdebug will also be disabled for any scripts that happen to be executed concurrently with this script.
In my development environment, this is an acceptable trade-off, given that Composer is executed manually and only occasionally; however you may not want to use this technique if executing Composer as part of an automated deployment process.
I came up with a solution for the Windows-based Composer installer - it should work for any Composer installation, it just basically makes a copy of the loaded INI file and comments out the xdebug zend extension, then loads that configuration file when it runs composer.
I've opened an issue to see if they'd like to integrate this change:
https://github.com/composer/windows-setup/issues/58
You can find my instructions and code there.
As noted in Joyce's answer, this issue no longer exists in the latest version of Composer.
The Composer documentation has been updated to note this. It details how you can enable xdebug with Composer (if required).
You can update your version of Composer by utilising self-update.
On my Mac I had to do: sudo php /opt/local/bin/composer self-update
Further details about this in the context of a Homebrew PHP install can be found in this issue.
Creating an alias for composer to disable xdebug and prevent memory errors:
Add this line to your ~/.bash_profile
alias composer='php -d xdebug.profiler_enable=0 -d memory_limit=-1 /usr/local/bin/composer'
Restart the terminal to make the new alias available.
In most cases you do not need xdebug on CLI mode. If this is acceptable for you than you can configure cli and cgi differently.
So if you make php-cli.ini and conf-cli.d near exiting php.ini file than you can configure cli and cgi differently (for cgi it would be php.ini and conf.d). Just do not put xdebug.ini into conf-cli.d.
If you install composer using brew on OS X
You can use this alias:
alias composer="php -n $(cat $(which composer) | grep composer.phar | awk '{print $7}')"
My quick solution for a macports installation, with multiple versions of PHP was to write this simple shell wrapper for Composer:
/user/local/bin/composer-nodebug.sh
#!/bin/bash
sudo mv /opt/local/var/db/php53/xdebug.ini /opt/local/var/db/php53/xdebug.NOT
sudo mv /opt/local/var/db/php54/xdebug.ini /opt/local/var/db/php54/xdebug.NOT
sudo mv /opt/local/var/db/php55/xdebug.ini /opt/local/var/db/php55/xdebug.NOT
composer $1 $2 $3 $4 $5 $6 $7
sudo mv /opt/local/var/db/php53/xdebug.NOT /opt/local/var/db/php53/xdebug.ini
sudo mv /opt/local/var/db/php54/xdebug.NOT /opt/local/var/db/php54/xdebug.ini
sudo mv /opt/local/var/db/php55/xdebug.NOT /opt/local/var/db/php55/xdebug.ini
Then run any composer commands like so:
sudo composer-nodebug.sh update
Drawbacks:
requires sudo (unless you chmod the INI files)
if you kill it mid-way the INI files are modified
will require future PHP versions added.
while it's running other PHP processes are affected
Not elegant, but simple.
(Windows)
Based on documentation I use environment variable PHPRC, so I can choose which INI file shloud be loaded, thus I can choose whether I want to enable or disable Xdebug before executing a command (like composer install).
I have two INI files, one with Xdebug enabled (php-xdebug.ini) and one with Xdebug disabled (php.ini - it's also default one).
I use some batches (placed in location which is included in PATH environment variable, so it can be executed from anywhere):
To enable Xdebug I call xon.bat:
#ECHO OFF
set PHPRC=C:/path-to-php/php-xdebug.ini
To disable Xdebug I call xoff.bat:
#ECHO OFF
set PHPRC=
By calling php --ini I can check which INI file was loaded.
Alternatively you can use environment variable PHP_INI_SCAN_DIR in which you set a path to directory from where additional INI files will be loaded. Advantage is that you can load multiple INI files.
Here is my quick solution to get rid off the Xdebug warning on PHP5-cli version. I have removed the support of Xdebug for PHP5-cli on Ubuntu 14.04.
cd /etc/php5/cli/conf.d/
sudo rm 20-xdebug.ini
Now no more Xdebug warning on PHP5-cli.
I have a problem with the installation of Sylius.
PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 126
This error occur when I run : composer create-project -s dev sylius/sylius-standard Club26
My configuration is :
Wamp on Win7 64bits (for Apache, PHP and MySQL)
I have git installed
I use cmder to run my command
I have changed memory_limit = 1024M in php.ini
I tried with composer install with Windows Setup, and with composer.phar
Thanks for help
Try disabling Garbage Collection during installation.
For global installations of Composer
$ php -d zend.enable_gc=0 `which composer` create-project -s dev sylius/sylius-standard Club26
For local installation of composer.phar
$ php -d zend.enable_gc=0 composer.phar create-project -s dev sylius/sylius-standard Club26
Just in case, I got also memory error during the execution of sylius:install
I set memory_limit to -1 to fix it
$ php -d memory_limit=-1 app/console sylius:install
I got a problem, I tried to install a new package to my Laravel 4 project.
But when I run php composer.phar update I get this:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Killed
I have looked for the problem in the Internet and saw that the memory is the problem, I think I don't have enough RAM available, I've checked this I have about 411mb free.
Does composer really need more RAM?
The "Killed" message usually means your process consumed too much memory, so you may simply need to add more memory to your system if possible. At the time of writing this answer, I've had to increase my virtual machine's memory to at least 768MB in order to get composer update to work in some situations.
However, if you're doing this on a live server, you shouldn't be using composer update at all. What you should instead do is:
Run composer update in a local environment (such as directly on your physical laptop/desktop, or a docker container/VM running on your laptop/desktop) where memory limitations shouldn't be as severe.
Upload or git push the composer.lock file.
Run composer install on the live server.
composer install will then read from the .lock file, fetching the exact same versions every time rather than finding the latest versions of every package. This makes your app less likely to break, and composer uses less memory.
Read more here: https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock
Alternatively, you can upload the entire vendor directory to the server, bypassing the need to run composer install at all, but then you should run composer dump-autoload --optimize.
If like me, you are using some micro VM lacking of memory, creating a swap file does the trick:
#Check free memory before
free -m
mkdir -p /var/_swap_
cd /var/_swap_
#Here, 2G ~ 2GB of swap memory. Feel free to add MORE
sudo fallocate -l 2G swapfile
chmod 600 swapfile
mkswap swapfile
swapon swapfile
#Automatically mount this swap partition at startup
echo "/var/_swap_/swapfile none swap sw 0 0" >> /etc/fstab
#Check free memory after
free -m
As several comments pointed out, don't forget to add sudo if you don't work as root.
btw, feel free to select another location/filename/size for the file.
/var is probably not the best place, but I don't know which place would be, and rarely care since tiny servers are mostly used for testing purposes.
Unfortuantely composer requires a lot of RAM & processing power. Here are a few things that I did, which combined, made the process bearable. This was on my cloud playpen env.
You may be simply running out of RAM. Enable swap: https://www.digitalocean.com/community/search?q=add+swap (note: I think best practice is to add a seperate partition. Digitalocean's guide is appropriate for their environment)
service mysql stop (kill your DB/mem-hog services to free some RAM - don't forget to start it again!)
use a secondary terminal session running top to watch memory/swap consumption until process is complete.
composer.phar update --prefer-dist -vvv (verbose output [still hangs at some points when working] and use distro zip files). Maybe try a --dry-run too?
Composer is apparently know to run slower in older versions of PHP (e.g. 5.3x). It was still slow in 5.5.9 for me...
DigitalOcean fix that does not require extra memory - activating swap, here is an example for 1gb:
in terminal run below
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1
The above solution will work until the next reboot, after that the swap would have to be reactivated. To persist it between the reboots add the swap file to fstab:
sudo nano /etc/fstab
open the above file add add below line to the file
/var/swap.1 swap swap sw 0 0
now restart the server. Composer require works fine.
I've got this error when I ran composer install inside my PHP DOCKER container,
It's a memory issue.
Solved by increasing SWAP memory in DOCKER PREFERENCES from 512MB to 1.5GB
To do that:
Docker -> Preferences -> Rousources
Increase the memory limit for composer
php -d memory_limit=4G /usr/local/bin/composer update
Run composer self-update and composer clearcache
remove vendor and composer.lock
restart your local environment and then run
php -d memory_limit=-1 /usr/local/bin/composer install
If you're using docker you can use COMPOSER_PROCESS_TIMEOUT
environment:
COMPOSER_MEMORY_LIMIT: -1
COMPOSER_PROCESS_TIMEOUT: 2000 #seconds
Also in big projects composer needs more RAM than 2GB, you can check that with ps -aux while it is running.
You will have to add it manually inside docker options, nothing else will help.
Here's how I succeeded in installing maatwebsite\excel package from composer in Laravel Framework:
I download composer.json file and composer.lock file from my remote server.
I run composer update from local command prompt (then wait until all the install process finished).
Upload composer.lock file to remote server.
run composer install on remote server (then wait until all process finished).
DONE
composer 2 update have reduced the memory usage
composer self-update
composer update
composer require xxx
Fix for AWS ec2 Ubuntu Server Php Memory Value Upgrade For Magento 2.3.X
Php 7.2 / 7.3
nginx
ubuntu
composer 1.X
mariaDB
magento 2.3.X
Error : Updating dependencies (including require-dev)
Killed
for
Ram Must at least 4GB
Change instance type to suitable or Upgrade Ram
Php Memory Value change
Server Restart
Try to install the same package again
PHP value update
may locate under '/etc/php/7.2/fpm/php.ini'
depend on your server and PHP fpm X.XX version
Using Seed command 'change as your server requires'
on my case >> /etc/php/7.2/fpm/php.ini
memory limit type as "3.5G" or "3500MB"
Php 7.2.X
sudo sed -i "s/memory_limit = .*/memory_limit = 3.5G/" /etc/php/7.2/fpm/php.ini
Php 7.3.X
sudo sed -i "s/memory_limit = .*/memory_limit = 3.5G/" /etc/php/7.3/fpm/php.ini
Test if applied on 'free -h' command
free -h
Install-Package Again#
Install extension via Composer
go to your Magento 2 installation directory
cd /var/www/html/
with 'superuser' privileges
sudo su
Start installation
composer require XXXXXX/XXXXXXX
Enable Module s
php bin/magento module:enable XXXXXX/XXXXXXX
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
Restart
sudo reboot
Enjioy
I was facing this same issue on my ec2 instance, following steps worked for me :
Copied composer.lock file from my local environment to ec2.
then run sudo composer install and its simply installed all the dependencies for my project.
I solved it maintaining the below steps in my ubuntu server. Hope it will works for you.
Stop my apache server
sudo service apache2 stop
Run composer update
sudo composer update
Start my apache server
sudo service apache2 start
php -d memory_limit=5G composer.phar update
I get this problem caused for a package that don't update correctly with wildcards, I use directly the last version and it works finally.
"l3/cas-bundle": "~1.0" -------> "l3/cas-bundle": "1.1.13"
Solved on Laravel/Homestead (Vagrant Windows)
Edit Homestead.yaml and increase memory from 2048 to 4096
vagrant up
vagrant ssh
Install Symfony with this line on the folder you choose (must be without files)
COMPOSER_MEMORY_LIMIT=-1 composer create-project symfony/website-skeleton . -s dev
I was using:
Virtualbox
4096 Gb RAM
2 CPU
10 GB HDD (500 MB swap)
Ubuntu 20.04
Running:
composer update in a laravel 8 project folder
I didn't set the swap for the virtual machine, so Virtualbox created a 500Mb swap space, which was NOT enough.
So composer was using 4Gb of RAM plus swap.
I gave more swap space to the VM and then it worked.
As the picture below, composer used all my RAM + 2GB of swap
System Monitor
You can try setting preferred-install to "dist" in Composer config.
I was getting this error in a local Docker environment. I solved it by simply restarting Docker.