Mit tegyünk, ha a Composer PHP csomagkezelő nagyon lassan halad, akadozik a projektek frissítése közben

botond küldte be 2020. 08. 16., v – 14:41 időpontban

Tartalom

 

A hibajelenség

Amikor a Composer PHP csomagkezelővel frissítünk egy projektet, akkor nagyon lassan halad előre a folyamat, sőt, akár úgy is tűnhet, mintha lefagyott volna a frissítés.

Amikor tehát kiadjuk például a következő composer frissítő parancsát:

composer update --with-dependencies

 

 

(Ebben a példában ennek a Drupal alapú oldalnak az itthoni szerveremen lévő másolatának frissítettem az alaprendszerét.)

Akkor elindul a frissítés, a kimenetre kikerül az első két sor:

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

De ez után nem történik semmi (látszólag). Itt ilyenkor normál esetben körülbelül 1 percnyi idő szokott eltelni, amíg felépíti a függőségeket, de itt hosszú 10 perc eltelte után sem történt semmi.

Egy idő itán megszakítva a folyamatot, majd újra futtatva a parancsot a -vvv debugolási kapcsolóval kiegészítve:

composer update -vvv --with-dependencies

Ezután már többet látunk:

A composer update parancs a -vvv debug kapcsolóval

A composer update parancs a -vvv debug kapcsolóval (2.)

Itt már látszik, hogy a folyamat az megy a háttérben, csak iszonyat lassan. Egy-egy Composer csomag letöltése a repóból több percet is igénybe vesz. Így a rengeteg csomag, és függőségeinek letöltése összesen akár sok-sok órát is igénybe vehet.

Mi a megoldás ilyenkor?

 

 

A megoldás

Az egyel ezelőtti frissítéskor nem volt semmi gond. Így végiggondoltam, hogy milyen körülmények változhattak azóta, és egyedül az internet szolgáltatásomban történt változás. Az új internetcsomagom már támogatja az IPv6-os IP-címet is. Így ebben az irányban utánajárva találtam rá a megoldásra.

Alapból nincs bekonfigurálva az IPv6-os cím a számítógépeken, így volt ez nálam is az itthoni szerveremen. Viszont vannak szolgáltatások, amik ilyenkor az IPv6-on próbálnak meg elsőként kommunikálni, attól függetlenül, hogy az nincs még beállítva. Ez történik ilyenkor a Composerrel is, amikor elsőként megpróbál az IPv6-on keresztül kapcsolódni a csomagtárához, de mivel nem tud kapcsolódni, egy idő után időtúllépéssel eldobja a kapcsolatot, majd átvált IPv4-re, és végül azzal letölti a csomagot. Majd a következő csomag letöltésénél kezdődik az egész előröl. Így a sok-sok csomag együttes letöltése nagyon sok időt venne igénybe.

Az megoldás tehát vagy az, hogy beállítjuk rendesen az IPv6-os címünket, vagy átállítjuk a rendszert, hogy az IPv4 legyen a preferált hálózati protokollunk. Mivel az első megoldás az egy külön témát foglal magában, így most itt az utóbbit választjuk, ami egy rendkívül egyszerű megoldás. Ehhez mindössze nyissuk meg a /etc/gai.conf fájlt rootként szerkesztésre:

sudo nano /etc/gai.conf

És az alábbi képen látható módon adjuk a fájl végéhez a következő sort:

[...]
precedence ::ffff:0:0/96 100

A /etc/gai.conf fájl szerkesztése

Vagy akár ezzel a paranccsal is egyszerűen hozzáadhatjuk:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

Ezután már normál sebességgel fog az IPv4 protokollon keresztül frissíteni a Composer.

 

Alternatív megoldás

Ha esetleg nem pont ez lenne a probléma, hanem mondjuk éppen a Composer alapértelmezett csomagtárát nem lehet elérni, akkor átállíthatjuk a Composert, hogy az angol csomagtárból dolgozzon. Ehhez adjuk ki az alábbi parancsot:

composer config repositories.packagist.org composer https://repo-eu-uk-1.packagist.org

Ezt átmeneti megoldásként használjuk, amíg rendbe nem jön a fő csomagtár elérhetetlensége. Ha később vissza szeretnénk állítani az alap csomagtárat, akkor adjuk ki ezt a parancsot:

composer config repositories.packagist.org --unset

 

 

Konklúzió

Nálam az első megoldás vált be, az IPv4 elsőbbségbe helyezése után már rendesen ment a Composer frissítése.

Remélem sikerül ezzel megspórolnom egy kis plusz keresgélést azoknak, akik esetleg pont ilyen hibával kerülnek szembe.