I have a very simple recipe that downloads composer.phar and installs all the dependencies for the package. While testing this recipe I ran into an a memory issue.
$sudo php composer.phar install Loading composer repositories with package information Installing dependencies - Installing symfony/event-dispatcher (dev-master 4b34aad) PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar:///srv/www/my_application_name/releases/20130603234158/composer.phar/vendor/symfony/console/Symfony/Component/Console/Application.php:975 Stack trace: #0 [internal function]: Composer\Util\ErrorHandler::handle(2, 'proc_open(): fo...', 'phar:///srv/www...', 975, Array) ...
A quick online search will revealed that composer memory issues while running small VMs is a common problem. I even had this issue in a local VM.
The simplest fix is to add more memory, but this could be a costly solution.
In my case I addressed the problem by doing the following two things:
- Ensure that the
composer.lockfile is part of the repository and/or it uses a new format
- Add Memory Swap to the EC2 Instance
Articles  and  in the references below describe how to add Memory Swap to address this issue. But memory swap all by itself will not help if the lock file is not present or has an outdated format. See here for more info.
It is also likely that new instances added to the OpsWorks layer will fail starting up because of the same issue. In this case you can create a new recipe to add swap on startup. This may be important if you have time based or load based instances.