Compositore ucciso durante l'aggiornamento

Ho un problema, ho provato a installare un nuovo pacchetto nel mio progetto Laravel 4. Ma quando corro php composer.phar updateottengo questo:

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

Ho cercato il problema in Internet e ho visto che il problema è la memoria, penso di non avere abbastanza RAM disponibile, ho controllato che ho circa 411 MB di spazio libero. Il compositore ha davvero bisogno di più RAM?

Il messaggio "Killed" di solito significa che il processo ha consumato troppa memoria, quindi potrebbe essere necessario aggiungere più memoria al sistema, se possibile. Al momento di scrivere questa risposta, ho dovuto aumentare la memoria della mia macchina virtuale ad almeno 768 MB per composer updatepoter lavorare in alcune situazioni.

Tuttavia, se lo stai facendo su un server live, non dovresti usarlo composer updateaffatto. Quello che dovresti invece fare è:

1. Esegui composer updatein un ambiente locale (come direttamente sul tuo laptop / desktop fisico o su un contenitore Docker / VM in esecuzione sul tuo laptop / desktop) dove i limiti di memoria non dovrebbero essere così gravi.
2. Carica o git pushil file composer.lock.
3. Esegui composer installsul server live.

composer installleggerà quindi dal file .lock, recuperando le stesse identiche versioni ogni volta invece di trovare le ultime versioni di ogni pacchetto. Ciò riduce le probabilità che l'app si rompa e il compositore utilizza meno memoria.

Leggi di più qui: https://getcomposer.org/doc/01-basic-usage.md#installing-with-composer-lock

In alternativa, puoi caricare l'intera vendordirectory sul server, evitando del tutto la necessità di eseguire composer install, ma poi dovresti eseguire composer dump-autoload --optimize.

Se come me stai usando qualche micro VM priva di memoria, la creazione di un file di scambio fa il trucco:

#Check free memory before
free -m

mkdir -p /var/_swap_
cd /var/_swap_
#Here, 1M * 2000 ~= 2GB of swap memory.  Feel free to add MORE
dd if=/dev/zero of=swapfile bs=1M count=2000
mkswap swapfile
swapon swapfile
chmod 600 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

Come sottolineato da diversi commenti, non dimenticare di aggiungere sudo se non lavori come root.

btw, sentiti libero di selezionare un'altra posizione / nome file / dimensione per il file.
/varprobabilmente non è il posto migliore, ma non so quale sarebbe il posto, e raramente mi interessa dato che i server minuscoli sono usati principalmente per scopi di test.

Sfortunatamente il compositore richiede molta RAM e potenza di elaborazione. Ecco alcune cose che ho fatto, che combinate, hanno reso il processo sopportabile. Questo era sul mio box cloud env.

1. Potresti semplicemente esaurire la RAM. Abilita lo scambio: https://www.digitalocean.com/community/search?q=add+swap (nota: penso che la migliore pratica sia aggiungere una partizione separata. La guida di Digitalocean è appropriata per il loro ambiente)
2. service mysql stop (uccidi i tuoi servizi DB / mem-hog per liberare un po 'di RAM - non dimenticare di riavviarlo!)
3. utilizzare una sessione di terminale secondaria in esecuzione topper controllare il consumo di memoria / scambio fino al completamento del processo.
4. composer.phar update --prefer-dist -vvv(output dettagliato [si blocca ancora in alcuni punti durante il lavoro] e utilizza file zip della distribuzione). Forse provare --dry-runanche tu?
5. Il compositore è apparentemente noto per funzionare più lentamente nelle versioni precedenti di PHP (ad esempio 5.3x). Era ancora lento nella 5.5.9 per me ...

Correzione di DigitalOcean che non richiede memoria aggiuntiva: attivazione dello swap, ecco un esempio per 1 GB:

nel terminale eseguito di seguito

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

La soluzione di cui sopra funzionerà fino al prossimo riavvio, dopodiché lo scambio dovrà essere riattivato. Per mantenerlo tra i riavvii, aggiungi il file di scambio a fstab:

sudo nano /etc/fstab

apri il file sopra aggiungi aggiungi sotto la riga al file

/var/swap.1 swap swap sw 0 0

ora riavvia il server. Il compositore richiede funziona bene.

Esegui composer self-updatee composer clearcache rimuovi vendor e composer.lock, riavvia l'ambiente locale e quindi esegui php -d memory_limit=-1 /usr/local/bin/composer install

Ho ricevuto questo errore quando ho eseguito composer installnel mio contenitore PHP DOCKER, è un problema di memoria. Risolto aumentando la memoria SWAP nelle PREFERENZE DOCKER da 512 MB a 1,5 GB

Aumenta il limite di memoria per il compositore

php -d memory_limit=4G /usr/local/bin/composer update

Potrebbe essere necessario riavviare dopo questa modifica

Ottengo questo problema causato da un pacchetto che non si aggiorna correttamente con i caratteri jolly, utilizzo direttamente l'ultima versione e finalmente funziona.

"l3 / cas-bundle": "~ 1.0" -------> "l3 / cas-bundle": "1.1.13"

Se stai usando docker puoi usare COMPOSER_PROCESS_TIMEOUT

Ecco come sono riuscito a installare il pacchetto maatwebsite \ excel dal compositore in Laravel Framework:

1. Ho scaricato composer.json di file e composer.lock file dal mio server remoto.
2. Eseguo composer updatedal prompt dei comandi locale (quindi aspetto fino al termine di tutto il processo di installazione).
3. Carica il file composer.lock sul server remoto.
4. eseguire composer installsul server remoto (quindi attendere fino al termine di tutto il processo).
5. FATTO

php -d memory_limit = 5G composer.phar aggiornamento

Risolto su Laravel / Homestead (Vagrant Windows)

1. Modifica Homestead.yamle aumenta la memoria da 2048 a 4096

2. vagabondare

3. vagabondo ssh

4. Installa Symfony con questa riga nella cartella che scegli (deve essere senza file)

   COMPOSER_MEMORY_LIMIT=-1 composer create-project symfony/website-skeleton . -s dev

Puoi provare a impostare preferred-installsu "dist"nella configurazione di Composer.

Ho ricevuto questo errore in un ambiente Docker locale. L'ho risolto semplicemente riavviando Docker.