Composer: Composer Update silently returns "Killed"

Created on 22 Apr 2013  路  27Comments  路  Source: composer/composer

Hi there,

when I try to execute the _composer update_ command I got a generic _Killed_ result.
After same tests I follow the Symfony and Composer guidelines to make a fresh installation of the framework entirely from the composer. Here's my steps and the resulting output:

$ composer create-project symfony/framework-standard-edition ./ 2.2.1 --prefer-dist

    Installing symfony/framework-standard-edition (v2.2.1)
      - Installing symfony/framework-standard-edition (v2.2.1)
        Loading from cache

    Created project in ./
    Loading composer repositories with package information
    Installing dependencies from lock file
      - Installing doctrine/lexer (v1.0)
        Loading from cache

      - Installing doctrine/annotations (v1.1)
        Loading from cache

      - Installing doctrine/cache (v1.0)
        Loading from cache

      - Installing doctrine/collections (v1.1)
        Loading from cache

      - Installing twig/twig (v1.12.2)
        Loading from cache

      - Installing psr/log (1.0.0)
        Loading from cache

      - Installing doctrine/inflector (v1.0)
        Loading from cache

      - Installing doctrine/common (2.4.0-RC1)
        Loading from cache

      - Installing symfony/symfony (v2.2.1)
        Loading from cache

      - Installing jdorn/sql-formatter (v1.2.0)
        Loading from cache

      - Installing doctrine/dbal (2.3.3)
        Loading from cache

      - Installing doctrine/doctrine-bundle (v1.2.0-beta1)
        Loading from cache

      - Installing doctrine/orm (2.3.3)
        Loading from cache

      - Installing jms/cg (1.0.0)
        Loading from cache

      - Installing phpoption/phpoption (1.2.0)
        Loading from cache

      - Installing jms/parser-lib (1.0.0)
        Loading from cache

      - Installing jms/metadata (1.3.0)
        Loading from cache

      - Installing jms/aop-bundle (1.0.0)
        Loading from cache

      - Installing jms/di-extra-bundle (1.3.0)
        Loading from cache

      - Installing jms/security-extra-bundle (1.4.0)
        Loading from cache

      - Installing sensio/distribution-bundle (v2.2.1)
        Loading from cache

      - Installing sensio/framework-extra-bundle (v2.2.1)
        Loading from cache

      - Installing sensio/generator-bundle (v2.2.1)
        Loading from cache

      - Installing kriswallsmith/assetic (v1.1.0-alpha4)
        Loading from cache

      - Installing symfony/assetic-bundle (v2.1.2)
        Loading from cache

      - Installing monolog/monolog (1.4.1)
        Loading from cache

      - Installing symfony/monolog-bundle (v2.2.0)
        Loading from cache

      - Installing swiftmailer/swiftmailer (v4.3.0)
        Loading from cache

      - Installing symfony/swiftmailer-bundle (v2.2.0)
        Loading from cache

      - Installing twig/extensions (v1.0.0)
        Loading from cache

    kriswallsmith/assetic suggests installing leafo/lessphp (Assetic provides the integration with the lessphp LESS compiler)
    kriswallsmith/assetic suggests installing leafo/scssphp (Assetic provides the integration with the scssphp SCSS compiler)
    kriswallsmith/assetic suggests installing leafo/scssphp-compass (Assetic provides the integration with the SCSS compass plugin)
    kriswallsmith/assetic suggests installing ptachoire/cssembed (Assetic provides the integration with phpcssembed to embed data uris)
    monolog/monolog suggests installing doctrine/couchdb (Allow sending log messages to a CouchDB server)
    monolog/monolog suggests installing ext-amqp (Allow sending log messages to an AMQP server (1.0+ required))
    monolog/monolog suggests installing ext-mongo (Allow sending log messages to a MongoDB server)
    monolog/monolog suggests installing mlehner/gelf-php (Allow sending log messages to a GrayLog2 server)
    monolog/monolog suggests installing raven/raven (Allow sending log messages to a Sentry server)
    Generating autoload files
    Clearing the cache for the dev environment with debug true
    Installing assets using the hard copy option
    Installing assets for Symfony\Bundle\FrameworkBundle into web/bundles/framework
    Installing assets for Acme\DemoBundle into web/bundles/acmedemo
    Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution
$ composer install

Loading composer repositories with package information
Installing dependencies from lock file
Nothing to install or update
Generating autoload files
Clearing the cache for the dev environment with debug true
Installing assets using the hard copy option
Installing assets for Symfony\Bundle\FrameworkBundle into web/bundles/framework
Installing assets for Acme\DemoBundle into web/bundles/acmedemo
Installing assets for Sensio\Bundle\DistributionBundle into web/bundles/sensiodistribution
$ composer update

    Loading composer repositories with package information
    Updating dependencies (including require-dev)
    Killed

Trying to require an external library I got the same error:

$ composer require "gregwar/image-bundle:dev-master"

    composer.json has been updated
    Loading composer repositories with package information
    Updating dependencies (including require-dev)
    Killed

I've the latest composer available versione and the diagnose tell me all is OK.

How can I make it works? Or how can I get more informations on the error?

Thanks in advance!

Most helpful comment

Another DigitalOcean fix that does not require extra memory - activating swap, here's an example for 1gb:

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

UPD since this comment gets some attention I'd like to update it: the above solution will work untill the next reboot, after that the swap would have to be reactivated. To persist it between reboots add the swap file to fstab: sudo nano /etc/fstab, the line to add for above file is /var/swap.1 swap swap sw 0 0

All 27 comments

My guess is "Killed" means the machine ran out of memory and oom-killer or a similar thing depending on your OS decided to kill the composer process.

you were right!! After increasing the performance of my server it worked like a charme!
Thanks again!!

No problem, 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.

I got the problem and followed the above advice by committing the generated composer.lock file. That fixed the problem - so thank you, @Seldaek!

Yeah, I also followed you advice and that solved my problem. Thank you very much.

All problems can have different sollutions. This was mine.
After Killed appeared, both on Vagrant and on OSX, I tried the following:

On the vagrant:
sudo composer update
-- failed

On osx:
sudo composer update
-- success

Just up the level on vb.memory = "1024" e.g.

Increasing the memory fixed my problem too, thank you !

When I have this kind of problem with composer, I just add some swap memory and it works. For Ubuntu, I like to follow this tutorial that explains the steps very well:

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

@victorhtorres thanks a lot. vb.memory = "1024" fixed my problem

@anacicconi thanks! you save my life.

For what it's worth, I experienced this using composer install on a DigitalOcean droplet with 512mb memory for the droplet. After increasing the memory limit of the droplet to 1gb, the issue went away.

Another DigitalOcean fix that does not require extra memory - activating swap, here's an example for 1gb:

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

UPD since this comment gets some attention I'd like to update it: the above solution will work untill the next reboot, after that the swap would have to be reactivated. To persist it between reboots add the swap file to fstab: sudo nano /etc/fstab, the line to add for above file is /var/swap.1 swap swap sw 0 0

After increasing the memory limit to "1024" I am still getting same error. Is there any other server configuration that should be optimize to solve this issue?

thanks

If you are experiencing this problem on an AWS EC2 instances, the solution is just to create a swap file and enable it, as explained in https://stackoverflow.com/questions/17173972/how-do-you-add-swap-to-an-ec2-instance:

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

@bcat-eu Thanks it works!

@bcat-eu Thank you so much!

@bcat-eu thanks bro, helped me

PHP kills the composer update process when out of memory:
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 651173888) (tried to allocate 20480 bytes) in /usr/share/php/Composer/DependencyResolver/Rule.php on line 66
Suggestion is to build at local computer and then just copy the files to the server.

one option is to run "composer update" multiple times till all packages get updated.

No problem, 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.

It saved my time and efforts thanks

Running composer update multiple times appeared to be working for me to some degree.

I鈥檓 also using Lando and what ultimately worked for me was lando restart which seems to have freed up enough memory to let me knock out one more substantial composer update without it getting killed. Just wanted to include this here, in case others using Lando are running into this problem.

Thanks so much. It works with a AWS Micro Edition Instance (Ubuntu 18 LTS)

@bcat-eu Thank you

I had this issue updating a module on my Drupal site running DDEV. It turns out the module requires PHP 7.2 and my setting in .ddev/config.yaml had PHP version set to 7.1. I changed it, restarted DDEV, and now ith works.

Was this page helpful?
0 / 5 - 0 ratings