Hoster Webgo

[tblumrich]

Also ich versuche ein Paket zu installieren, egal ob über den Manager oder über den Konsolenaufruf "php71 contao-manager.phar.php composer require paket/paketname"
Hier bekomme ich Fehler (siehe oben).

Wenn ich danach aber "php71 contao-manager.phar.php composer update" aufrufe, wird das Paket installiert.

Ich kann so arbeiten, kein Ding, aber gedacht ist das dann doch anders, oder?

Wenn der Composer dort global installiert sein sollte, wo fände ich den? Und dann rufe ich den dort einfach via "composer require paket/paketname" auf, wenn ich was installieren will?
Sorry, aber ich bin ja bereit alles zu lernen und erstmal überall zu lesen, aber intuitiv und userfriendly ist nach modernen Gesichtspunkten m.M. nach echt anders...

Gruß
Thomas

[mlweb]

Wenn der Composer dort global installiert sein sollte, wo fände ich den?

/usr/bin/php7.2 /usr/bin/composer ...

PHP-Version ggf. anpassen.
Was ich meinte war dann composer install
Composer Update funktioniert in meinem Problem-Paket grundsätzlich auch nicht.

[mlweb]

Bei Webgo sollte eigentlich Composer global installiert sein, ob der mittlerweile auch aktuell ist bzw sich aktualisieren lässt weiss ich allerdings nicht.

Nach meinem etwas ärgerlichen Hinweis diesbezüglich ist er auf allen Paketen nach Aussage des Supports aktualisiert. Ich habs auf allen Paketen, deren ich habhaft werden konnte kontrolliert.
Nur composer aufrufen ist allerdings schlecht. Dann wird er nach Aussagen des Supports mit PHP 5.6 aufgerufen und das wollen wir ja in den meisten Fällen nicht.

[tblumrich]

Auch so bekomme ich Out of Memory, wenn ich direkt den Composer direkt nutze.

Wenn ich danach composer update aufrufe wird das Paket installiert.
composer install läuft auch durch, es wird aber gemeldet:

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them.

[tab]

Vermutlich bist du hart an der Grenze des verfügbaren RAMs und das require verbraucht noch ein paar Extrabytes beim Runterladen des Pakets. Danach ist das Paket schon da und in die json eingetragen und es reicht deshalb gerade so.

Was ich mich frage ist, ob es Sinn macht, im Manager bzw in der json nicht überall einfach "neueste" zu benutzen. Kann man eventuell irgendwie ältere Versionen ausschliessen und würde das eventuell RAM einsparen? Also z.B. Composer "mitteilen", dass man von keinem Paket eine ältere Version haben will als aktuell installiert? Das würde dann allerdings bedeuten, dass man beim Update eine neuere Contao-Version nicht installiert bekommt, die z.B. ein aktuell installiertes Paket, von dem es keine neuere Version gibt, als conflict eingetragen hat. Sowas gabs ja auch schon mal, damals wurde die Verwendung einer älteren Version des Pakets damit erzwungen, was dann hier nicht klappen würde.

[mlweb]

Auch so bekomme ich Out of Memory, wenn ich direkt den Composer direkt nutze.

Wie Du den Composer aufrufst (ob über Manager oder Konsole) ändert ja nichts am tatsächlichen Speicherbedarf.
Umgekehrt kann es ein Unterschied zwischen dem Speicher geben der Deinem Prozess über den Manager zugebilligt wird und dem der Dir über die Konsole zur Verfügung steht.

[Cranker]

Ich habe für meine Kunden mehrfach Platinpakete im Einsatz. Das Problem tritt bei mir nur bei einem einzigen Paket auf. Insofern bin ich da noch relativ gelassen und arbeite im Moment mit lokalem Update und Übertragung der composer.lock. Der Aufwand dafür hält sich ja Gott sei Dank in Grenzen.

Ich habe nun das gleiche Problem, wie genau machst du das Update?
Du überträgst deine lokale composer.lock Datei auf den Server - und dann?

[Spooky]

php7.1 composer.phar install -o

ausführen. Oder wenn du die composer.phar nicht heruntergeladen hast, dafür aber den Contao Manager verwendest:

php7.1 web/contao-manager.phar.php composer install -o

Oder direkt im Contao Manager unter Maintenance » Composer Dependencies » Run Installer.

[Cranker]

Großartig!
Danke!

Nun habe ich meine Installation wieder retten können :-)
Dort habe ich nach einem mißglückten Update nur noch einen Error beim Aufruf des Managers bekommen...

[Spooky]

Leider ist der Contao Manager immer noch zu abhängig von der eigentlichen Contao Installation - obwohl er das nicht sein müsste. Ich hoffe das wird noch geändert.

[Cranker]

Ich hatte gestern und heute 3x Kontakt mit dem webgo Support, weil ich auf dem Server s136 mit einem Platin-Paket bei einer Contao 4.4.13 Installation keine Erweiterung installieren konnte.

Using version ^1.4 for codefog/contao-cookiebar
/home/www/xxx/composer.json has been updated
Loading composer repositories with package information
Updating dependencies

mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory

Process terminated with exit code 255
Reason: Unknown error

Die eigentliche Installation und das hinzufügen von Erweiterungen hat vor wenigen Wochen aber problemlos geklappt...

Als erstes habe ich die Empfehlung bekommen in der php.ini das Speicherlimit von 256M auf 512M zu setzen.
Das hat aber keinen Unterschied gemacht.

Also habe ich noch mal angerufen. Da habe ich erfahren, das es ein bekannter Bug mit Contao 4.4 und den aktuellen Versionen von MySQL(?) ist und das ich mal nach "Contao 4.4 Cannot allocate memory mysql fix" suchen soll - da würde ich verschiedene Einträge dazu finden. Die Einträge habe ich aber nicht gefunden.
Das Problem soll wohl auch in der Contao 4.5 behoben sein... - warum dann nicht in der 4.4?

Weiß da jemand was dazu?
Habe ich nur falsch gesucht?

Also habe ich heute Morgen noch mal angerufen um das Problem zu klären und hatte Herr Da Silva dran - ich glaube das ist einer der besten Leute dort, der hat mir bisher immer sofort helfen können.
Leider nicht bei diesem Problem...

Er hat aber festgestellt, das bei der Fehlermeldung immer die exakt gleiche Zahl an fehlendem Speicher steht - sehr unwahrscheinlich das dies wirklich so der Fall ist wenn ich mehrfach versuche die gleiche oder auch andere Erweiterungen zu installieren. Er hat auch kurzfristig das Speicher-Limit auf 1GB hoch gesetzt - gleiche Fehlermeldung.

Danach habe ich entdeckt das ich noch einen andern Kunden auf dem gleichen Server s136 habe - allerdings ein Power-Paket.
Dort gibt es keine Problem! Updaten oder Erweiterungen installieren geht beides problemlos.

Das hilft zwar alles nicht, weil das Problem noch immer besteht, aber vielleicht kann irgendjemand damit mehr anfangen und das Problem dadurch einkreisen?

Ach ja: Nachdem ich Dank @Spooky meine Installation retten konnte und ein Update auf die aktuelle Contao 4.4.16 gemacht habe, bestand das Problem leider immer noch - die Installation von Erweiterungen ist nicht möglich. Ich denke auch ein Update über den Manager wird mir die Installation wieder zerschiessen - nun weiß ich aber zumindest wie ich diese wieder retten kann...

[Spooky]

Als erstes habe ich die Empfehlung bekommen in der php.ini das Speicherlimit von 256M auf 512M zu setzen.
Das hat aber keinen Unterschied gemacht.

Das kann auch keine Auswirkung haben. Laut der Fehlermeldung wird der maximale Speicherverbrauch jedes Prozesses, zumindest für deinen SSH User, generell limitiert.

Also habe ich noch mal angerufen. Da habe ich erfahren, das es ein bekannter Bug mit Contao 4.4 und den aktuellen Versionen von MySQL(?) ist und das ich mal nach "Contao 4.4 Cannot allocate memory mysql fix" suchen soll - da würde ich verschiedene Einträge dazu finden. Die Einträge habe ich aber nicht gefunden.
Das Problem soll wohl auch in der Contao 4.5 behoben sein... - warum dann nicht in der 4.4?

Diese Aussage ist nicht richtig.

Ach ja: Nachdem ich Dank @Spooky meine Installation retten konnte und ein Update auf die aktuelle Contao 4.4.16 gemacht habe, bestand das Problem leider immer noch - die Installation von Erweiterungen ist nicht möglich. Ich denke auch ein Update über den Manager wird mir die Installation wieder zerschiessen - nun weiß ich aber zumindest wie ich diese wieder retten kann...

Dir bleibt momentan wohl nichts anderes über als alle Erweiterungen zuerst immer lokal installieren und dann auf dem Server ein composer install zu machen (über den Contao Manager oder über SSH).

[Cranker]

Das kann auch keine Auswirkung haben. Laut der Fehlermeldung wird der maximale Speicherverbrauch jedes Prozesses, zumindest für deinen SSH User, generell limitiert.

Das war noch der Versuch normal über den Manager - aber das ist wahrscheinlich das gleiche!?

Diese Aussage ist nicht richtig.

Davon gehe ich auch aus, aber darum frage ich was es damit auf sich hat...
Der Support Mitarbeiter "Da Silva" wusste davon auch nix.

Dir bleibt momentan wohl nichts anderes über als alle Erweiterungen zuerst immer lokal installieren und dann auf dem Server ein composer install zu machen (über den Contao Manager oder über SSH).

Ja das denke ich auch.
Ich habe gerade noch mal ein paar Tests gemacht:

Server s122 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s129 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s133 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s136 - CMS Pro Paket => OK Update & Installation von Erweiterungen möglich
Server s136 - CMS Power Paket => OK Update & Installation von Erweiterungen möglich
Server s143 - CMS Power Paket => OK Update & Installation von Erweiterungen möglich

Server s124 - CMS Platin Paket => ERROR Installation von Erweiterungen nicht möglich
Server s136 - CMS Platin Paket => ERROR Installation von Erweiterungen nicht möglich

Scheint wohl am Platin-Paket zu liegen!?

[Spooky]

Wie gesagt, auf dem Server (bei welchem Paket auch immer), scheint der maximale Speicherverbrauch für alle Prozesse deines Users (SSH, Webserver, …) hart eingeschränkt zu sein.

[Cranker]

Wie gesagt, auf dem Server (bei welchem Paket auch immer), scheint der maximale Speicherverbrauch für alle Prozesse deines Users (SSH, Webserver, …) hart eingeschränkt zu sein.

Aber genau das scheint doch nicht zu stimmen!?
Ich habe das Problem bei zwei verschiednen Servern (s124, s136) mit dem Platin Paket, aber auf dem einen Server (s136) eben nicht mit zwei anderen Paketen (Pro & Power).

Demnach ist es eben nicht Server- sondern Paket-Abhängig.