Composer Fehler nach Live Update von 3.5.3 auf 3.5.14: Fatal error: Out of memory

Hallo zusammen,

vorweg: ich bin keinProfi, nur ambitionierter Anwender,
habe bislang alles hinbekommen.

Gestern wollte ich mir "etwas Gutes" tun und hab eine Live Update ID gekauft und das laufen lassen.

der erste Fehler war einfach zu finden...ich hatte eine Variable genutzt, welche nicht definiert wurde (für Farbdarstellung, also nichts Wildes)

was mich aber stört kann ich selber nicht beeinflussen:

Code:

---

Fatal error: Out of memory (allocated 231211008) (tried to allocate 36 bytes) in phar:///mnt/strato/document/root/htdocs/2016/composer/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 61

---

ich merke es bisher nur, wenn ich im Repository bzw. erweiterung installieren möchte
(mir gelingt es nämlich nicht, den TinyMCE wieder optisch so aufzuhübschen, wie er früher war)
das sind auch die einzigen installierten Erweiterungen, welche ich nutze, zum TinyMCE

Kennt das jemand?

Frank

Die 220.5MiB RAM die du zur Verfügung hast oder hattest sind für die composer Operation nicht ausreichend. Du musst das memory_limit erhöhen oder den comooser im detached mode ausführen lassen.

ich such parallel schon in einem anderen Thread..habe nun mal anders die Suche gefüllt.

Was ich da nur nicht verstehe:
es hat vorher einwandfrei funktioniert (3.5.3)
warum prüft das Live Update das nicht, sondern lässt es Problemlos durchlaufen? genau dafür ist das doch gedacht: vereinfachen.

ich hab diesen Strato Account ehrenamltich übernommen und bin mir nicht sicher, ob ich etwas ändern kann

detached Mode? mus sich mal suchen
Limit erhöhen beim Webpaket eher schwierig denke ich

Zitat:

---

Zitat von supergrobi

detached Mode? mus sich mal suchen

---

In einem deutschsprachigen Backend heisst das 'als eigenständigen Prozess ausführen' und findet sich in System -> Einstellungen.

Zitat:

---

Zitat von supergrobi

Limit erhöhen beim Webpaket eher schwierig denke ich

---

Es mag auch helfen wenn Du in -> Paketverwaltung -> Einstellungen -> Minimale Stabilität auf 'Stable' stellst.

beides probiert..gleiches ergebnis ;)

hänge im Support und hinterfrage nunmal, wieviel ram da zur Verfügung steht.

Ich fürchte, dass es nicht arg viel sein wird ;)

und Ergebnis: 128MB bei Strato...ui....
oder halt Server oder vServer
und da hängen 2 alte Seiten hinter mit 15 Jahren archiv, was von verschiedensten Menschen aufgesetzt wurde
auch erhöhen der php.ini hat 0 Erfolg sagte mir der gute Mensch direkt

Zitat:

---

Zitat von supergrobi

Was ich da nur nicht verstehe:
es hat vorher einwandfrei funktioniert (3.5.3)

---

Je nach Requirements, Dependencies und Versionen der Pakete kann die Komplexität einer composer Operation unterschiedlich hoch sein.

Zitat:

---

Zitat von supergrobi

warum prüft das Live Update das nicht, sondern lässt es Problemlos durchlaufen? genau dafür ist das doch gedacht: vereinfachen.

---

Das Live Update hat ja nichts mit der Paketverwaltung zu tun.

Zitat:

---

Zitat von supergrobi

beides probiert..gleiches ergebnis ;)

---

Poste mal die Konsolen Ausgabe des Detached Mode.

Zitat:

---

Zitat von Spooky

Je nach Requirements, Dependencies und Versionen der Pakete kann die Komplexität einer composer Operation unterschiedlich hoch sein.


Das Live Update hat ja nichts mit der Paketverwaltung zu tun.


Poste mal die Konsolen Ausgabe des Detached Mode.

---

aber hat das Live Update nicht auch den Composer mit aktualisiert?
an Erweiterungen hab ich ja nicht mehr drauf....fast gar nichts eher gesagt.

Code:

---

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --dry-run
X-Powered-By: PHP/5.5.35
Content-type: text/html

Warning: Composer should be invoked via the CLI version of PHP, not the cgi-fcgi SAPI
sh: sudo: not found
Loading composer repositories with package information
Updating dependencies (including require-dev)
PHP Fatal error:  Out of memory (allocated 230948864) (tried to allocate 20 bytes) in phar:///mnt/Pfad/htdocs/2016/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60

Fatal error: Out of memory (allocated 230948864) (tried to allocate 20 bytes) in phar:///mnt/Pfad/htdocs/2016/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60

---

Zitat:

---

Zitat von supergrobi

aber hat das Live Update nicht auch den Composer mit aktualisiert?
an Erweiterungen hab ich ja nicht mehr drauf....fast gar nichts eher gesagt.

---

Hm, wäre mir neu, allerdings verwende ich das Live Update nicht - evt. irre ich mich da.

Zitat:

---

Zitat von supergrobi

Code:

---

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --dry-run
X-Powered-By: PHP/5.5.35
Content-type: text/html

Warning: Composer should be invoked via the CLI version of PHP, not the cgi-fcgi SAPI
sh: sudo: not found
Loading composer repositories with package information
Updating dependencies (including require-dev)
PHP Fatal error:  Out of memory (allocated 230948864) (tried to allocate 20 bytes) in phar:///mnt/Pfad/htdocs/2016/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60

Fatal error: Out of memory (allocated 230948864) (tried to allocate 20 bytes) in phar:///mnt/Pfad/htdocs/2016/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60

---

---

Ok, dann steht dir bei diesem Webhosting Paket auch über die Konsole nicht mehr RAM zur Verfügung - zumindest nicht über diese PHP binary. Evt. gibt es auf dem Server noch eine php-cli binary oder ähnliches, die du benutzen könntest.

ginge denn ein Downgrade?
(ohne Backup)

ich find das jetzt nicht dramatisch, kann so natürlich gar nichts installieren an Erweiterungen.
ist für JETZT ok, aber was bringt die Zukunft? Kann ich derzeit halt nicht sagen

Zitat:

---

Zitat von supergrobi

ginge denn ein Downgrade?
(ohne Backup)

---

Ein Downgrade von Contao meinst du? Das wird dir bzgl. dem composer Problem wahrscheinlich nichts bringen.

und ganu das verstehe ich nicht...
denn es ging ja noch alles gestern - bis ich das Live/Auto Update gemacht habe.
Also muss doch etwas geändert worden sein.

- keine Erweiterungen
- nichts am Webhostung Paket
- nur das Update/Upgrade

meine bescheidene Logik sagt dann, dass irgendwas mehr Speicher benötigt ;)
oder sehe ich das falsch, wenn vorher alles lief?

Zitat:

---

Zitat von supergrobi

und ganu das verstehe ich nicht...
denn es ging ja noch alles gestern - bis ich das Live/Auto Update gemacht habe.
Also muss doch etwas geändert worden sein.

- keine Erweiterungen
- nichts am Webhostung Paket
- nur das Update/Upgrade

meine bescheidene Logik sagt dann, dass irgendwas mehr Speicher benötigt ;)
oder sehe ich das falsch, wenn vorher alles lief?

---

Das heißt, als du gestern ein composer update gemacht hast, ist diese Operation fehlerfrei durch gelaufen und jetzt nach dem Update, wird mehr RAM für die composer Operation benötigt?

Zitat:

---

Zitat von Spooky

Das heißt, als du gestern ein composer update gemacht hast, ist diese Operation fehlerfrei durch gelaufen und jetzt nach dem Update, wird mehr RAM für die composer Operation benötigt?

---

es kam ja keine Fehlermeldung des Speicherüberlaufs.

Ich hätte das auch niemals gemerkt, wenn ich nicht gern das "alte" TinyMCE Layout wieder hätte.

was ich also nur gemacht habe vor dem Update: 1-2 Erweiterungen deinstalliert und neu installiert.
Immer zuerst den Testlauf, dann "richtig" - keine Fehlermeldung

dann Update (in der Hoffnung das es dann mit den Erweiterungen klappt ohne Eingriff)
und dann hatte ich die Fehlermeldung

ach..bin auf PHP 5.5 seh ich grad...dürfte das Besserung bringen upzudaten?

könnte ich das durch wechsel auf das alte repository beheben?
Mehr Speicher bekomme ich nicht.
Aber ich glaube, dort wird nichts mehr gepflegt, oder?

ich möchte darauf nochmals zurück kommen.

was ich inzwischen versucht / gemacht habe:
Auto Downgrade auf 3.5.4:
fehler bleibt - also weiter probiert

ich habe nun parallel eine neue DB eingerichtet, 3.5.4
auf anderer subdomain installiert.
identische 3 erweiterungen via Composer installiert,
alles auf gleicher Versionsnummer

DB habe ich noch nicht überspielt, auch meine minimalen Anpassungen noch nicht,
und es läuft - keine Probleme im Composer.
wie kann es denn dann sein, dass nach dem Auto Update auf 3.5.14 der Speicherüberlauf kommt,
in der frischen 3.5.4 mit gleichem Composer nicht?

Das Update hat keine Fehler gemeldet.

und das Wichtigste:

wie bekomme ich das schnelltmöglich nun ans laufen?
alles händisch übertragen?

Zitat:

---

Zitat von supergrobi

in der frischen 3.5.4 mit gleichem Composer nicht?

---

Was meinst du mit "gleichem Composer"?

Zitat:

---

Zitat von Spooky

Was meinst du mit "gleichem Composer"?

---

sorry...
gleiche Version
da ich in der Originalem aus September 2015 sicher eine frühere Version hatte

Der Speicherverbrauch hängt aber primär von der notwendigen Operation ab, nicht von der Version des composer-client, des copmoser-plugin oder composer selbst. Daher kannst du auch theoretisch nicht den Speicherverbrauch, der unter Contao 3.5.4 gilt, mit dem Speicherverbrauch, der unter Contao 3.5.14 notwendig ist, vergleichen, da zwischen den Versionen bei gewissen Paketen evt. andere Abhängigkeiten gelten.

Zitat:

---

Zitat von Spooky

Der Speicherverbrauch hängt aber primär von der notwendigen Operation ab, nicht von der Version des composer-client, des copmoser-plugin oder composer selbst. Daher kannst du auch theoretisch nicht den Speicherverbrauch, der unter Contao 3.5.4 gilt, mit dem Speicherverbrauch, der unter Contao 3.5.14 notwendig ist, vergleichen, da zwischen den Versionen bei gewissen Paketen evt. andere Abhängigkeiten gelten.

---

da ich mit dem Server und dem 15 Jahres Archiv nicht umziehen kann, und ich vermute alles neu aufzusetzen auf einem Vserver zu kompliziert wäre:

soll ich besser auf 3.5.4 bleiben?
DB hab ich schon migriert, grad noch die "Optik" -
scheint alles zu laufen

was mich aber wundert:
bei den Möglichkeiten, "inaktive Erweiterungen" auszuwählen habe ich in der clean install version
wesentlich weniger auswahlmöglichkeiten.
also in der nicht funktionierenden Verison hab ich locker 15+ erweiterungen, obwohl in der Paketverwaltung
identische Pakete installiert sind.

Ich vermute, da ist mal irgendwo etwas schief gelaufen

Frank

Zitat:

---

Zitat von supergrobi

was mich aber wundert:
bei den Möglichkeiten, "inaktive Erweiterungen" auszuwählen habe ich in der clean install version
wesentlich weniger auswahlmöglichkeiten.
also in der nicht funktionierenden Verison hab ich locker 15+ erweiterungen, obwohl in der Paketverwaltung
identische Pakete installiert sind.

Ich vermute, da ist mal irgendwo etwas schief gelaufen

---

Bei "Inaktive Erweiterungen" siehst du alle Erweiterungen, die tatsächlich in /system/modules installiert sind.

Hallo,

grundsätzlich sollte man in einem Produktivsystem kein composer update durchführen. Ein composer update prüft die Abhängigkeiten zwischen den installierten Paketen und sucht nach neuen Versionen, die zu den Einträgen in der composer.json passen. Danach werden die Pakete aktualisiert und die composer.lock neu geschrieben. Wie viel Arbeitsspeicher der composer dabei benötigt, hängt zum einen von der Anzahl der installierten Pakete und deren Abhängigkeiten aber auch von der verwendeten PHP-Version ab! Ich hatte schon Projekte, bei denen 1GB memory-limit gerade so gereicht haben.

In einem Produktivsystem führt man normalerweise ein composer install aus. Dabei schaut der composer, ob es eine gültige composer.lock gibt, und installiert die Pakete anhand der Einträge in der composer.lock. Dies ist erheblich schneller und benötigt wesentlich weniger Speicher. Schlägt dies fehl, wird im Prinzip das gleiche ausgeführt wie beim composer update.

Warum sollte man es vermeiden, im Produktivsystem ein composer update auszuführen?

In der composer.lock sind die Versionen hinterlegt, mit denen auf dem Entwicklungssystem gearbeitet und getestet wurde. Man kann also davon ausgehen, dass diese Kombination fast immer funktioniert. Beim composer update werden die zu installierenden Versionen der Pakete anhand der in der composer.json festgelegten Regeln neu ermittelt. Wenn die Regeln korrekt hinterlegt sind und sich die Entwickler der Pakete an die üblichen Regeln gehalten haben, sollte das auch funktionieren. Dennoch hatte ich schon Fälle, in denen das schief ging. Also besser: composer install!

Viele Grüße
Oliver

Zitat:

---

Zitat von ofriedrich

Hallo,

In der composer.lock sind die Versionen hinterlegt, mit denen auf dem Entwicklungssystem gearbeitet und getestet wurde. Man kann also davon ausgehen, dass diese Kombination fast immer funktioniert. Beim composer update werden die zu installierenden Versionen der Pakete anhand der in der composer.json festgelegten Regeln neu ermittelt. Wenn die Regeln korrekt hinterlegt sind und sich die Entwickler der Pakete an die üblichen Regeln gehalten haben, sollte das auch funktionieren. Dennoch hatte ich schon Fälle, in denen das schief ging. Also besser: composer install!

Viele Grüße
Oliver

---

super, danke
ich verstehe dann nur immer noch nicht, warum der Fehler erst auftrat nach Update von 3.5.4 auf 3.5.14
vielleicht setze ich das ganze nochmal neu auf und werde das Update nochmal durchführen.
mich interessiert woher das kam.
ja... ich hab mit erweiterungen "experimentiert", die aber (so dachte ich) deinstalliert.
dem scheint aber nicht so

Frank

und ein Update:

gleicher Fehler mit Live Update bei der frischen Installation.
nur die DB habe ich eingespielt und das files verzeichnis

3.5.4 funktionierte alles
3.5.14 wieder Fatal error mit Speicher

aber der Weg zurück hat diesmal scheinbar funktioniert

Ich habe doch jetzt schon in mehreren Posts versucht zu erklären, warum das so sein könnte...

Zitat:

---

Zitat von Spooky

Ich habe doch jetzt schon in mehreren Posts versucht zu erklären, warum das so sein könnte...

---

ja, und das schätze ich sehr.
Wie Du aber bemerkt haben könntest versuche ich zur Fehlerfindung beizutragen.
ich könnte es einfach sein lassen und mit 3.5.4 weitermachen.

Irgendwo in den Versionen zwischen 3.5.4 und 3.5.14 muss die Änderung ja stattgefunden haben.
wenn ich die Zeit finde werde ich langsam Rückwärts gehen mit den Versionen.

Weiterhin kann es ja helfen zu wissen, dass Strato beim normalen Webspace lediglich 128MB Speicher
zur Verfügung stellt.
somit wäre ein Strato als Webspace zumindest ab 3.5.14 ungeeignet.

naja..läuft ja..mal sehen was ich mache

Danke

Zitat:

---

Zitat von supergrobi

Irgendwo in den Versionen zwischen 3.5.4 und 3.5.14 muss die Änderung ja stattgefunden haben.

---

Die Änderung ist die Version selbst. Wie ich schon mehrmals gesagt habe, verbraucht die bei dir spezifisch geforderte Composer Operation unter Contao 3.5.14 einfach mehr Speicher als unter 3.5.4, möglicherweise aufgrund der geänderten Situation von Abhängigkeiten. Das ist an und für sich auch kein Fehler.

Zitat:

---

Zitat von ofriedrich

Hallo,

grundsätzlich sollte man in einem Produktivsystem kein composer update durchführen. Ein composer update prüft die Abhängigkeiten zwischen den installierten Paketen und sucht nach neuen Versionen, die zu den Einträgen in der composer.json passen. Danach werden die Pakete aktualisiert und die composer.lock neu geschrieben. Wie viel Arbeitsspeicher der composer dabei benötigt, hängt zum einen von der Anzahl der installierten Pakete und deren Abhängigkeiten aber auch von der verwendeten PHP-Version ab! Ich hatte schon Projekte, bei denen 1GB memory-limit gerade so gereicht haben.

In einem Produktivsystem führt man normalerweise ein composer install aus. Dabei schaut der composer, ob es eine gültige composer.lock gibt, und installiert die Pakete anhand der Einträge in der composer.lock. Dies ist erheblich schneller und benötigt wesentlich weniger Speicher. Schlägt dies fehl, wird im Prinzip das gleiche ausgeführt wie beim composer update.

Warum sollte man es vermeiden, im Produktivsystem ein composer update auszuführen?

In der composer.lock sind die Versionen hinterlegt, mit denen auf dem Entwicklungssystem gearbeitet und getestet wurde. Man kann also davon ausgehen, dass diese Kombination fast immer funktioniert. Beim composer update werden die zu installierenden Versionen der Pakete anhand der in der composer.json festgelegten Regeln neu ermittelt. Wenn die Regeln korrekt hinterlegt sind und sich die Entwickler der Pakete an die üblichen Regeln gehalten haben, sollte das auch funktionieren. Dennoch hatte ich schon Fälle, in denen das schief ging. Also besser: composer install!

Viele Grüße
Oliver

---

composer install unterstützt der composer-client leider immer noch nicht, daher kann man das nur machen, wenn man Zugriff zur Konsole am Webserver hat.

Zitat:

---

Zitat von Spooky

Die Änderung ist die Version selbst. Wie ich schon mehrmals gesagt habe, verbraucht die bei dir spezifisch geforderte Composer Operation unter Contao 3.5.14 einfach mehr Speicher als unter 3.5.4, möglicherweise aufgrund der geänderten Situation von Abhängigkeiten. Das ist an und für sich auch kein Fehler.

---

die "spezifisch" geforderte Composer Operation ist, um das mal zu verdeutlichen,
bei 2 installierten und funktionierenden erweiterungen zu TinyMCE
lediglich ein "Testlauf" ohne jede weitere Operation.
keine ausgewählte zusätzliche Erweiterung, kein Update - gar nichts.

die geänderte Situation von Abhängigkeiten gibt es also nur bezogen auf das Update.
und das habe ICH schon mehrmals gesagt.

Wenn also eine 3.5.4 mit den 2 erweiterungen den testlauf problemlos durchläuft
und ich ausser dem Update nichts ändere, nach dem Update aber genau der gleiche klick einen
Fehler verursacht...
ja dann würde mich doch sehr interessieren, wo da eine spezifisch geforderte Composer Operation mehr speicher
benötigt, welche aber nicht durch das Update hervorgerufen wird.

Zitat:

---

Zitat von supergrobi

die "spezifisch" geforderte Composer Operation ist, um das mal zu verdeutlichen,
bei 2 installierten und funktionierenden erweiterungen zu TinyMCE
lediglich ein "Testlauf" ohne jede weitere Operation.
keine ausgewählte zusätzliche Erweiterung, kein Update - gar nichts.

die geänderte Situation von Abhängigkeiten gibt es also nur bezogen auf das Update.
und das habe ICH schon mehrmals gesagt.

Wenn also eine 3.5.4 mit den 2 erweiterungen den testlauf problemlos durchläuft
und ich ausser dem Update nichts ändere, nach dem Update aber genau der gleiche klick einen
Fehler verursacht...

---

Ja, und durch die Erhöhung der Contao Version ändert sich ja auch potentiell die Situation der Abhängigkeiten. Sprich, bei Contao 3.5.14 kann der dependency graph komplexer sein als in Contao 3.5.4. Oder gerade mal so anders, dass ein Quäntchen zu viel Speicher benötigt wird.

Du wirst wahrscheinlich keinen Fehler in dem Sinn finden können.

Zitat:

---

Zitat von Spooky

Ja, und durch die Erhöhung der Contao Version ändert sich ja auch potentiell die Situation der Abhängigkeiten. Sprich, bei Contao 3.5.14 kann der dependency graph komplexer sein als in Contao 3.5.4. Oder gerade mal so anders, dass mehr ein Quäntchen zu viel Speicher benötigt wird.

Du wirst wahrscheinlich keinen Fehler in dem Sinn finden können.

---

mit DER Aussage kann ich leben.
aber verstehst Du, wenn jemand auch be Strato ist und den thread verfolgt/mal findet versuche ich zumindest eine max Version rauszufinden,
welche noch möglich ist.

ich hab nun die Wahl: bleibe ich lieber auf der 3.5.4, da die ja läuft, und riskiere damit, verbesserungen zu verpassen?
oder nehm ich einen V-Server dazu?
ganz wechseln käme mehreren Wochen Arbeit gleich, was ich als Ehrenamtler nicht stemmen kann (und will)

werd mal bei Strato anrufen und hinterfragen, was da möglich ist

Du kannst auch dort bleiben, composer updates immer lokal durchführen und das Ergebnis auf den Server deployen (da muss man aber auch auf die eine oder andere Sache achten).

Zitat:

---

Zitat von Spooky

Du kannst auch dort bleiben, composer updates immer lokal durchführen und das Ergebnis auf den Server deployen (da muss man aber auch auf die eine oder andere Sache achten).

---

ich bin mit Linux seit jeher auf Kriegsfuß, daher versuche ich das zu umgehen.
derzeitiger Gedanke ist ein Windows V-Server im gleichen Paket,
dann auf das Hostingpaket verweisen.

allerdings hab ich zu 2.x Zeiten mal eine lokale typolight installation gehabt..keine Ahnung,
ob das heute auch noch so einfach geht

Zitat:

---

Zitat von supergrobi

ich bin mit Linux seit jeher auf Kriegsfuß, daher versuche ich das zu umgehen.

---

Du brauchst ja nicht unbedingt Linux dafür.

Windows vserver läuft,
contao installiert 3.5.4
Datenbanl migriert
einstellungen laufen

DNS noch nicht geändert (zum Zugriff, da 2 unterschiedliche Pakete)
SSl Fehler gelöst

werde aber noch einen Thread aufmachen müssen bzgl Composers ;)
der ist laut Composer Check installiert, aber Contao sagt: nicht installiert

was ich dabei aber gesehen habe: der Composer ist laut repository freigegeben bis 3.5.12

hier zum neuen Thema