4.4.x Manager stopt mit exit code 137 und shh composer update mit "getötet".

[rwaelty1944]

Hallo Zusammen

Nach 3 Tagen wollte ich wieder einmal ein Packet update (Contao 4.4.17) mit dem Manager (beta17) machen. Systemprüfung ok. Ganze Systemwartung gemacht. Der Manager stoppt mit der Konsolenausgabe:



und ein ssh composer update zeigt folgendes:



Hat jemand vielleicht eine Antwort auf dieses Problem. Das Font- und das Backend funktioniert ganz normal.

Gruss Rolf

[Spooky]

Welcher Hoster?

[rwaelty1944]

Cyon.

[tab]

Evntuell braucht das Update länger als dein Hoster zulässt.

[rwaelty1944]

Vielen Dank. Ok ich versuche Morgen einmal mit ihnen zu reden und melde mich wieder.
Gruss Rolf

[rwaelty1944]

Spooky und tab das war das Problem, ich habe die max_execution_time von 100 auf 200 erhöht und alles funktioniert wieder perfekt. Die max. Zeit die eingestellt werden kann ist 300, also noch Reseve
Ich danke Euch Beiden vielmals.

Liebe Grüsse
Rolf

[lucina]

Nachrichtlich, falls jemand sucht: Mich hat das auch getroffen - allerdings mit bereits auf 300 Sekunden festgelegter Ausführungszeit. Allerdings hat ein entschlossener Klick auf 'Pakete aktualisieren' dann alles brav nachinstalliert. Möglicherweise eine Macke des Managers in Beta17.

[rwaelty1944]

Lucina Du siehst Deine e-mail hat gewirkt und wir sind glücklich mit Contao 4.4.17. Unser Web läuft perfekt.

Liebe Grüsse
Rolf

[lucina]

Fein, das freut mich :-)

[tab]

Nachrichtlich, falls jemand sucht: Mich hat das auch getroffen - allerdings mit bereits auf 300 Sekunden festgelegter Ausführungszeit. Allerdings hat ein entschlossener Klick auf 'Pakete aktualisieren' dann alles brav nachinstalliert. Möglicherweise eine Macke des Managers in Beta17.

Das scheint im Wesentlichen ein ähnliches oder gleiches Verhalten zu sein wie bei mir und anderen der "mmap-Fehler" bei Webgo und anderswo. Auch hier hilft der entschlossene Klick auf Pakete aktualisieren. Spricht also einiges für eine Macke im Manager Beta17.

[Spooky]

Darauf hat der Contao Manager keinen Einfluss.

[tab]

Das mag sein, der Code vom Contao-Manager selbst vielleicht nicht, aber vielleicht eine oder mehrere der Abhängigkeiten. Ich frag mich halt: Was ist anders, wenn ich
a) eine zusätzliche Erweiterung installiere
b) die Pakete aktualisiere

Punkt b) braucht offenbar sehr viel weniger RAM und läuft wohl auch nicht so lang, obwohl beide Male laut Konsolenausgabe die Abhängigkeiten aufgelöst werden und ggf neue Versionen heruntergeladen werden müssen. Bei der Laufzeit kann ich mir immerhin vorstellen, dass er vielleicht im ersten Anlauf die Abhängigkeiten aufgelöst, die composer.lock geschrieben hat und dann beim Runterladen und Installieren der Pakete die Zeit überschritten hat. Dann muss er im zweiten Anlauf beim Pakete aktualisieren die Abhängigkeiten eventuell nicht mehr neu auflösen (Ist das so? Ich weiss es nicht.), sondern nur noch die bereits festgelegten Pakete herunterladen und installieren. Beim RAM habe ich leider gar keine Vorstellung, wie das eventuell passieren könnte, weil wir uns ja immer einig waren, dass das Auflösen der Abhängigkeiten das meiste RAM braucht. Und das macht er angeblich beide Male. Trotzdem schmiert die Installation der Erweiterung ab, selbst wenn es nur eine absolut frische Installation ist ohne jegliche installierte Erweiterungen. Wir vermuten wegen zu wenig RAM. Danach läuft aber das Aktualisieren der Pakete problemlos durch, selbst wenn schon 10 oder mehr Erweiterungen installiert sind. Und die Erweiterungen sind korrekt installiert und funktionieren auch. Wie soll das gehen, wenn es an zu wenig RAM liegt? Dass er nach der relativ kurzen Zeit bis zum Absturz eventuell doch schon die Abhängigkeiten aufgelöst hat kann ich nicht recht glauben. Dieser Arbeitsschritt dauert beim Aktualisieren länger. Also was passiert da? Wenn wir das herausfinden, dann haben wir vermutlich einen Bug in einem der beteiligten Programmpakete gefunden, (Contao-Manager, Symfony, Composer, PHP, Zend, ...?) oder es ist doch ein Konfigurationsproblem, dass sich da auf sehr merkwürdige Weise zeigt.

[Spooky]

Das mag sein, der Code vom Contao-Manager selbst vielleicht nicht, aber vielleicht eine oder mehrere der Abhängigkeiten.

Der Contao Manager selbst hat aber keine Abhängigkeiten

[tab]

Na dann ist er es halt doch selbst, bzw halt PHP. Bei mir 7.1, ich stelle morgen mal auf 7.2 um, ob es da auch so ist. Das wird allerdings auch nichts beweisen können, selbst wenn es funktioniert. Könnte ja immer auch eine fehlerhafte Konfiguration von PHP 7.1 sein und eine korrekte von PHP 5.2. Aber was könnte da falsch konfiguriert sein? Wie lässt sich das Verhalten erklären? Warum braucht der Manager erst mehr RAM und danach weniger für die Auflösung der Abhängigkeiten? Wird durch den Fehler vielleicht RAM freigegeben das zuvor in den Untiefen des PHP Speichermanagements noch reserviert war?

Ich muss morgen auch mal mit Uberspace vergleichen, die stellen immer so schön viele PHP-Versionen zur Verfügung .

[Spooky]

Der Composer braucht den RAM, nicht der Manager.