Server Composer Install --No-Dev Killed

Composer killed while updating

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:

1. 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.
2. Upload or git push the composer.lock file.
3. 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.

Server composer install --no-dev killed

It looks like composer install is trying to update packages, so you probably does not have composer.lock file in your project. In that case composer install works like composer update which requires a lot of memory. Your server probably does not have enough memory and process gets killed by OS.

The easiest way of solving this would be to generate composer.lock on dev environment, commit it into project, and then run composer install on server on project with composer.lock. Installing dependencies from composer.lock is cheap, so there should not be any memory-related problems.

If you can't do this, you need to more memory on your server - either enable swap or buy server with more RAM.

composer update process killed

Run the composer update command on your development machine, which generates the composer.lock file for you. Upload that composer.lock file and on the shared host just run composer install. This will use a lot less memory!

composer is killed automatically from SSH

Thank you @Matteo,

Is it possible that the problem is the remaining amount of RAM available on the server?

I've verified the amount memory limit but do not think this is the problem.

php-cli -i | grep memory

However, I've solved my problem. In fact there are three ways to fix it:

1. Install a bundle without Composer

This is not a recommended solution , but usually is very useful know how to do it, especially in projects that are very outdated and you're worried about the problems that can be generated by the command composer update

This guide assumes you have no memory limit problems on your local server and therefore all commands work fine with composer .

First, you have to install the bundle in your local machine, e.g:

composer require jms/serializer-bundle

After you have installed the package, you just need to add the bundle to your AppKernel.php file:

// in AppKernel::registerBundles()
  $bundles = array(
  // ...
  new JMS\SerializerBundle\JMSSerializerBundle(),
  // ...
);

Second, open composer.json from your bundle directory, e.g.

// \vendor\jms\serializer-bundle\JMS\SerializerBundle\composer.json
"require": {
    "php": ">=5.4.0",
    "jms/serializer": "^1.0.0",
    "phpoption/phpoption": "^1.1.0",
    "symfony/framework-bundle": "~2.3|~3.0"
},

For each bundle in the "require section", open the corresponding composer.json to identify all the required bundles .

The aim is to copy the directories of all these bundles and upload them to the remote server in the "vendor " directory ( taking care to maintain the same large hierarchy of directories)

e.g:

if you open composer.json from jms/serializer bundle you can see:

// vendor/jms/serializer/composer.json
"require": {
    "php": ">=5.4.0",
    "jms/metadata": "~1.1",
    "jms/parser-lib": "1.*",
    "phpcollection/phpcollection": "~0.1",
    "doctrine/annotations": "1.*",
    "doctrine/instantiator": "~1.0.3"
},

Now, you should open composer.json from jms/metadata, jms/parser-lib and phpcollection/phpcollection to identify the others bundles that you have to upload to the remote server.

The goal is that no dependencies are missing.

finally, open /vendor/composer/autoload_namespaces.php from remote server and add all namespaces of your bundle dependencies. You should compare this file with you locally "autoload_namespaces.php".

2. Adding Swap Space

You have three options: create a new swap partition, create a new swap file, or extend swap on an existing LVM2 logical volume. It is recommended that you extend an existing logical volume.

3. update composer in local to only install in remote

This is the recommended option to make a good programming practice . When composer update is done on a third project , We don't know what can be happen wrong but when you have enough time for development and the project will be yours from now, you should have the project fully upgraded. First update on your local server with composer update and resolve all conflicts that arise . Finally, with the composer.json and composer.lock updated on the server, from now and forever only need to run a composer install to install and update all dependencies for the new bundles.

Matteo's explanation is correct, the composer update command occupies much more memory than composer install.

But just so you know, you typically should run update on your machine, then commit/deploy the composer.lock file and only run install on your server to sync up the dependencies with the lock file, to make sure you only get stuff you tested properly. That way you can also run a server with low memory without any problems.

Composer require output message Killed

SOLVED:

I using VM and I allow 1 Gb ram for nginx server.
In some reason solarium bundle is need over 2Gb ram to install.

To check how much ram is used while composer install you can add

--profile

at end of composer command, in this case it was

composer require nelmio/solarium-bundle --profile

dockerfile: `composer install --no-dev installs dev-dependencies, then deletes them straight away after

Pretty simple: you run composer update (which will update the list of packages, and install them), and afterwards you run composer install --no-dev.

Just out of curiosity: this is only done when updating the Docker image. Is there any good reason for this? Why don't you decouple the image and the source code running in that image?

Why running composer install --no-dev I got error with Barryvdh\Debugbar\ServiceProvider?

Before running

composer install --no-dev

1) Clear bootstrap/cache subdirectory as mentioned above
2) remove /vendor/ directory if you have it
3) Remove from config/app.php  ll lines with :

Barryvdh\Debugbar

Composer hanging while updating dependencies

So it turns out the problem was with php's xdebug extension. After disabling it in my php.ini, composer ran without any problems.

And just to note, the hang-up wasn't actually occurring while reading files from the cache. It was the step right after where composer was trying to resolve dependencies. It just never finished that step and never printed the output. That's why no matter what I did, it always appeared to be stuck reading a file from the cache.

---

Related Topics