Hoster Webgo

Ich hatte das Problem auch nur kurz. Hatte kurz Kontakt mit dem Support und wurde sofort gefixt.

Aber kann es sein, das die Performance stark eingebrochen ist?
Ich kann den Manager quasi ohne Memory Fehler nicht mehr nutzen... das ging bis vor kurzen einwandfrei mit meinem Paket (Platin).

Code:

---

Error: "Out of memory (allocated 1046487040) (tried to allocate 4096 bytes)" in phar:///home/www/***/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/Solver.php on 220


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

---

Kommt quasi egal bei welcher Erweiterung. Der Manager-Check sagt alles i.O.

Hat da jemand ähnliche Erfahrungen?

Ja die Erfahrung, dass bei einem Platin Paket plötzlich keine Updates mehr funktionieren habe ich auch gemacht. Dabei ist es egal ob Manager oder Konsole. Ich bin da schon seit einiger Zeit in Kontakt mit Webgo bisher aber leider noch ohne Ergebnis.

Das wäre schade, passt allerdings irgendwie auch mit meiner Beobachtung zusammen, dass bereits seit längerer Zeit Googles durchschnittliche Ladezeiten für Seiten deutlich höher sind als ursprünglich. Circa 200ms mehr pro Seite. Hatte das ursprünglich auf die durchgeführte Umstellung auf https mit Let's Encrypt geschoben, weil das in etwa zeitgleich passiert war.

Dies spiegelt sich leider nicht mit unseren Beobachtungen im Bezug auf die Ladezeit. Stichprobenartig konnten wir eine Verbesserung der Ladezeiten von bis zu 150% beobachten, in keinem Test gab es höhere Ladezeiten als vor dem Update. Wir haben ca. 200 Webseiten auf verschiedenen Servern getestet.

Ebenfalls ist apc/apcu hinzu gekommen, welches aktiviert ist und direkt verwendet werden kann.

Im Bezug auf das Memory Problem sind derzeit noch interne Tests nötig um definitiv sagen zu können woher das Problem kommt.

Zitat:

---

Zitat von mlweb

Ja die Erfahrung, dass bei einem Platin Paket plötzlich keine Updates mehr funktionieren habe ich auch gemacht. Dabei ist es egal ob Manager oder Konsole. Ich bin da schon seit einiger Zeit in Kontakt mit Webgo bisher aber leider noch ohne Ergebnis.

---

Das klingt nicht sehr erbaulich, leider.
Dabei war ich sehr zufrieden und am Überlegen dauerhaft bei WebGo anzusiedeln.

Gefühlt muss ich das von tab geschilderte auch bestätigen... seit geraumer Zeit gibts immer mal sehr verzögerte Antwortzeiten.

Ich kann das Problem auch nicht eindeutig zuordnen. Sonst hätte ich schon länger mal nachgefragt. Es hat mit der jetzigen Änderung auch sicher nichts zu tun, denn die Änderung der Ladezeiten ist jetzt schon fast 3 Monate her. Es war eben auffällig, dass plötzlich statt Ladezeiten von meist unter 200ms in der Crawling-Statistik praktisch von einem Tag zum anderen 350-450ms angezeigt wurde und auch die dort angezeigte durchschnittliche Ladezeit entsprechend höher wurde. In etwa zu der Zeit habe ich aber ein Contao-Update gemacht und auch auf https umgestellt. Vielleicht liegt es ja daran - oder Google misst jetzt einfach irgendwie anders. Nachdem Google Pagespeed immer noch jenseits der 95 liegt, kann es eigentlich auch nicht so furchtbar schlimm sein. Deshalb habe ich da bisher nichts unternommen. Werde jetzt aber doch nochmals genauer in die Installationen reinschauen, ob ich dabei vielleicht irgendwas verbogen habe.

Zitat:

---

Zitat von tblumrich

Das klingt nicht sehr erbaulich, leider.

---

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.

Zitat:

---

Zitat von mlweb

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.

---

Kannst du mal kurz skizzieren, wie der Weg konkret aussieht oder gibts dafür irgendwo eine Anleitung oder was wissenswertes...? Lokal entwickle ich nämlich garnicht.
Das wäre vielleicht für brennende Upgrades eine Variante.

Danke!

PS: Die Konsole hat bei meinem Paket wohl scheinbar nur 5.6.30 als PHP Version. Kann das ein möglicher Grund sein?

Zitat:

---

Zitat von tblumrich

Kannst du mal kurz skizzieren, wie der Weg konkret aussieht oder gibts dafür irgendwo eine Anleitung oder was wissenswertes...? Lokal entwickle ich nämlich garnicht.

---

lokal arbeite ich mit XAMPP unter Windows 10. Da unter Windows der Manager noch nicht funktioniert läuft dort alles über die Konsole. Wie man bei wenig RAM dann alles auf den Server bekommt hat @Spooky einige Male erklärt u.a. in diesem Post

Zitat:

---

Zitat von tblumrich

PS: Die Konsole hat bei meinem Paket wohl scheinbar nur 5.6.30 als PHP Version.

---

Ist mir bei den Platin-Paketen noch nicht untergekommen. Ich hatte immer auch 7.0 und 7.1 auf der Konsole und im Paket zur Verfügung.
Fakt ist dass der Speicherbedarf bei 5.6 höher ist.

Hallo liebes Webgo-Team,
ich habe mir heute ein CMS Power zugelegt.

Gehe ich auf die Konsole steigen mir schon wieder leicht die Nackenhaare zu Berge. Egal ob ich PHP 7.1 oder 7.2 benutze, es kommt die Warnmeldung

Code:

---

PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/readline.so' - /usr/lib/php/20160303/readline.so: undefined symbol: rl_on_new_line in Unknown on line 0

---

Ich dachte das sollte auf allen Paketen der Vergangenheit angehören.
Auch ein Zertifikats-Problem besteht dort scheinbar.
Eure Composer Version ist inzwischen so alt, dass ich damit nicht mehr arbeiten möchte, weil ich nicht weiß ob einige Probleme daher kommen. Eine aktuelle krieg ich aber nicht zu fassen.

Code:

---

wget https://getcomposer.org/download/1.6.3/composer.phar
--2018-02-13 14:09:03--  https://getcomposer.org/download/1.6.3/composer.phar
Resolving getcomposer.org (getcomposer.org)... 54.36.53.46, 2001:41d0:302:1100::8:104f
Connecting to getcomposer.org (getcomposer.org)|54.36.53.46|:443... connected.
ERROR: The certificate of 'getcomposer.org' is not trusted.
ERROR: The certificate of 'getcomposer.org' hasn't got a known issuer.

---

Versuche ich es dann doch mit eurer composer-Version 1.4.2 habe ich natürlich erwartungsgemäß das Zertifikatsproblem:

Code:

---

PHP Warning:  PHP Startup: Unable to load dynamic library 'readline.so' (tried: /usr/lib/php/20170718/readline.so (/usr/lib/php/20170718/readline.so: undefined symbol: rl_on_new_line), /usr/lib/php/20170718/readline.so.so (/usr/lib/php/20170718/readline.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
 
 
  [Composer\Downloader\TransportException]
  The "https://packagist.org/packages.json" file could not be downloaded: SSL
  operation failed with code 1. OpenSSL Error messages:
  error:1416F086:SSL routines:tls_process_server_certificate:certificate veri
  fy failed
  Failed to enable crypto
  failed to open stream: operation failed
 
 
create-project [-s|--stability STABILITY] [--prefer-source] [--prefer-dist] [--repository REPOSITORY] [--repository-url REPOSITORY-URL] [--dev] [--no-dev] [--no-custom-installers] [--no-scripts] [--no-progress] [--no-secure-http] [--keep-vcs] [--no-install] [--ignore-platform-reqs] [--] [<package>] [<directory>] [<version>]

---

Ich bin etwas angesäuert.
Wie gesagt ich bin kein Entwickler und auch kein Serveradministrator. Normalerweise mag ich mich mit diesem Bereich nicht rumschlagen und mir fehlt dazu auch das nötige Wissen, sonst würde ich einen eigenen Server administrieren. Ihr zwingt mich allerdings derzeit gerade dazu mich viel intensiver mit der Problematik zu befassen, als das eigentlich bei einem Shared Hosting Paket erforderlich sein sollte
Gerade nach dem letzten Wirbel hier im Forum habe ich anderes erwartet.

Huhu, das Zertifikatsproblem auf der Konsole hat bei mir der Support nach dem letzten Update bei zwei Paketen behoben. Bei PHP 7.2 habe ich ebenfalls das readline.so Problem, bin wieder zurück auf 7.1, da funktioniert es mittlerweile, ebenfalls aber erst nach Ticketerstellung, wieder. Momentan bin ich da auch etwas enttäuscht, bin von 1&1 sowie von Domainfactory teilweise zu Webgo umgezogen wegen den dortigen Unzulänglichkeiten wie Composer, Laufzeitproblemen etc. Jetzt habe ich wieder Baustellen, nur anderer Art. Unglaublich....


Gesendet von iPad mit Tapatalk

Hatte die Info auch an den Support gegeben weil ich ohnehin noch in Kontakt bin wegen eines Paketes mit anderen Problemen.
Man hat mir versichert, dass man das auf allen Systemen prüfen wird und auch den global installierten Composer updaten wird.
Für mein Paket wurde es definitiv gerade behoben. Der Composer ist upgedatet. Das Zertifikatsproblem wurde auch behoben.
Damit bin ich erst einmal zufrieden. Danke an Webgo.

Zitat:

---

Zitat von mlweb

Danke an Webgo.

---

Der Support funktioniert wirklich gut, keine Frage. Ärgerlich ist nur, dass man diesen wegen solchen Sachen braucht :-).

Ich denke es ist gerade eine schwere Zeit. Von PHP5 auf PHP 7 und dann die neuen Anforderungen wegen des Composers. Webgo ist auf jedenfall der einzige Provider den ich kenne, welcher sich hier im Forum meldet und sich wirklich der Probleme annimmt. Ich habe gerade gestern noch versucht Contao 4 auf einem großen Hetzner L19 Paket zu installieren und dort ist Schluss, sobald man versucht eine Erweiterung zu installieren. Bei anderen Kunden kann ich kein kostenloses Let'sEncrypt aufsetzen.

Ich bin jetzt bestimmt schon 12 Jahre bei Webgo und bisher gab es dort keine Probleme. Also auch mal ein Dank an den Support von Webgo und natürlich bin ich selber auch daran interessiert, dass dort demnächst alles wieder reibungslos läuft.

Auch einen Dank an alle, welche ihre Probleme beim Support melden, denn ich profitiere schließlich auch davon ;)

Wollte nur auch kurz vermelden, das gestern wohl ein Fehler in der Hardware entdeckt und die Nacht entsprechendes Equipment getauscht wurde. Das ganze wurde gestern zeitig angekündigt. Seither hab ich zumindest wieder die gewohnte Performance, auch ohne jede Probleme mit dem Manager/Composer.
Prima! :D

Einer meiner Server ist am Sonntag dran.

Ja, meiner von Sonntag auf Montag, da bin ich ja mal gespannt ...

Checkt danach bitte euere MariaDBs im Webspace-Admin. Die wurden bei mir dort schon nicht angezeigt und somit liefen die natürlich auch nicht in meinen Installationen. Es wurde sofort gefixt und sie sollten es jetzt im Griff haben, schaut aber bitte trotzdem dort nach.

Ich werde in jedem Fall vorher noch ein Backup fahren und runterladen. Man hat schon Pferde ko**en sehen... ;)

Hallo,
ich finde bei WebGo kein Platin-Webhostingpaket, nur Starter, Profi, Business und Power.
Ist das Platinpaket ein älteres Paket und kann nicht mehr gebucht werden?
Wer hat Erfahrungen zum aktuellen Business-Paket und Contao 4.4.x?
Kann ich beim Business-Paket je Subdomain eine andere PHP-Version wählen oder nur eine PHP-Persion für das gesamte Paket?
Danke für die Infos.
Schmidty

Also ich denke das mit der PHP-Version ist bei Webgo bei allen Paketen gleich. Man kann sie leider momentan nur global einstellen :(. Das ist das einzige Problem dort, das mich wirklich stört.
Wegen Platin-Paket, das war mal eine Aktion. Ich geb keine Links mehr dazu raus, aber Google findet es problemlos :cool:.

Ich weiß nicht wirklich wo das hingehört. Hier oder in den Thread wo gerade über Problemchen mit dem CM diskutiert wird.
Ich hab wieder Probleme bei Webgo... erst war es sehr wechselhaft, mal lassen sich Erweiterung installieren, mal nicht.

Versuche ich im Moment den CM zu nutzen, gibt es bei der Installation Fehler:

Code:

---

Error: "Out of memory (allocated 1046487040) (tried to allocate 2359296 bytes)" in phar:///home/www/die-zettelfee.de/web/contao-manager.phar.php/vendor/composer/composer/src/Composer/DependencyResolver/Transaction.php on 123


mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

In Transaction.php line 123:
                                                                             
  [Symfony\Component\Debug\Exception\OutOfMemoryException]                   
  Error: Out of memory (allocated 1046487040) (tried to allocate 2359296 byte 
  s)                                                                         
                                                                             

Exception trace:

tenside:runtask [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [--disable-events] [--] <command> <taskId>



Process terminated with exit code 255
Reason: Unknown error

---

Rufe ich dann die Konsole auf und versuche es da, passiert z.B.:

Code:

---

php71 contao-manager.phar.php composer require glumanda99/contao-rellax
Using version ^1.0 for glumanda99/contao-rellax
/home/www/die-zettelfee.de/composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory

---

Jetzt versuche ich auf der Konsole das Update, läuft es durch...

Code:

---

php71 contao-manager.phar.php composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing glumanda99/contao-rellax (1.0): Loading from cache
Writing lock file
Generating autoload files
> ComponentInstaller\Installer::postAutoloadDump
Compiling component files
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication

 Added/updated the web/app_dev.php file.
 Added/updated the web/app.php file.

---

Der Support kann mir im Moment auch nicht wirklich weiter helfen, weils mal geht, mal nicht.
Wie gesagt, es ging auch schon problemlos mit dem Paket und dem CM.

Was kann ich tun?

Ich bin da auch gerade dran an diesem Problem. Bei mir betrifft es seit etwa Mitte Januar ein Platin-Paket auf dem Server s86. Ist in dem Fall mein eigenes.
Ich habe noch weitere Kundenpakete bei denen das nicht der Fall ist. Alles andere Server.
Magst Du Deinen Server bekannt geben, bei dem es bei Dir passiert?

Ich arbeite auf dem Server im Moment für meine Liveinstallation über composer install.

Ah, okay... das "beruhigt" mich etwas. Hin und hergerissen zwischen Manager Problemen und Hoster, war ich jetzt wirklich ratlos wonach man suchen soll. Der Supporter bei Webgo denkt mittlerweile auch, was soll das.

Mein Server ist s136 - ebenfalls ein Platin-Paket.

Ganz blöde Frage. Wenn ich alles bisher mit dem Manager gemacht habe bzw. den per Konsole angeschubst habe... wie bediene ich dann per Konsole den Composer direkt? Oder würde das keinen Unterschied machen...? :o

edit: Wie gezeigt: "php71 contao-manager.phar.php composer require paket/paketname" funktioniert nicht. Allerdings, wenn ich danach das Update anschiebe via "php71 contao-manager.phar.php composer update" -> dann wird das Paket installiert.


Gruß
Thomas

Was meinst du mit "per Konsole angeschubst"? Hast du den in der contao-manager.phar enthaltenenen Composer über die Konsole aufgerufen? Du kannst dir von getcomposer.org jederzeit eine composer.phar runterladen und entweder ins Installationsverzeichnis (nicht /web/) schieben und von dort aufrufen. Oder, wenn es dir bei deinem Hoster möglich ist, composer global zu installieren, so dass du ihn aus jedem Verzeichnis heraus einfach als "composer" aufrufen kannst. Bei Webgo sollte eigentlich Composer global installiert sein, ob der mittlerweile auch aktuell ist bzw sich aktualisieren lässt weiss ich allerdings nicht.

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

Zitat:

---

Zitat von tblumrich

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.

Zitat:

---

Zitat von tab

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.

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:

Code:

---

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.

---

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.

Zitat:

---

Zitat von tblumrich

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.

Zitat:

---

Zitat von mlweb

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?

Code:

---

php7.1 composer.phar install -o

---

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

Code:

---

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

---

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

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...

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.

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.

Code:

---

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...

Zitat:

---

Zitat von Cranker

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.

Zitat:

---

Zitat von Cranker

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.

Zitat:

---

Zitat von Cranker

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).

Zitat:

---

Zitat von Spooky

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!?

Zitat:

---

Zitat von Spooky

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.

Zitat:

---

Zitat von Spooky

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!?

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.

Zitat:

---

Zitat von 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.

---

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.

Ah ok, ja kann schon sein :). Mit der Information kannst du ja nun wieder zum WebGo Support gehen.

Da wäre vielleicht mal ein klärendes Wort seitens Webgo hilfreich, damit jeder weiß, woran er mit welchem Paket ist.
Also einfach eine kleine Tabelle, in der für die verschiedenen Pakete aufgelistet wird, wie das maximale RAM aussieht für

1. Normaler Websitezugriff (Seitenaufrufe)
2. Composer-Aufruf aus der Konsole
3. Composer-Aufruf über Contao-Manager

Dass es Beschränkungen gibt, ist ja per se nichts Böses. Geht halt nicht ohne, der Gesamtspeicher des Servers ist nun mal limitiert und andere User auf dem Server möchten vielleicht auch mal ein paar KB RAM nutzen ;). Kann ja auch nicht sein, dass alle anderen Fehlermeldungen bekommen, bloss weil ich gerade ein "composer update" ausführen will. Wahrscheinlich werden manche Limits auch nicht fix sein, sondern von der Anzahl der User auf dem Server sowie deren Paketen, der Anzahl aktiver Prozesse oder wovon auch immer abhängen. Das darf dann gern mit angegeben werden, ebenso eventuelle feste Minimal- und Maximalwerte, also wieviel RAM bekomme ich jeweils garantiert und wieviel kann ich maximal bekommen. Dann eventuell noch eine Aussage, wie die Zahlen zu verstehen sind, pro Prozess oder pro User oder ...?

Dann kann man auch besser abschätzen, welches Paket man braucht für ein Projekt. Oder, wie in meinem Fall, welches Paket ich mir leisten muss, um notfalls Updates für Kundeninstallationen in anderen Paketen bei Webgo durchführen zu können Ok, das geht natürlich notfalls immer lokal, ist aber bequemer "von Webgo zu Webgo". Ich will meinen Kunden keine "falschen" Pakete "verkaufen" (ich verkaufe kein Hosting, den Vertrag mit dem Hoster schliesst bei mir letztlich immer der Kunde selbst ab, aus vielerlei Gründen. Ich spreche also lediglich eine Empfehlung aus). "Falsche" Pakete wären dann aus meiner Sicht solche, die unter- oder deutlich überdimensioniert sind für den "Normalbetrieb" der Website. Ich will also niemandem einen Power-Paket empfehlen, nur weil er für das Update die 2GB RAM braucht, wenn seine Seite eh nur recht moderate Zugriffszahlen haben wird und im Normalbetrieb mit 32MB pro Zugriff auskommt. Da reicht dann auch ein kleineres Paket mit 256 oder 512MB RAM und das Update macht man halt woanders. Umgekehrt will ich auch niemandem ein Starter-Paket empfehlen, wenn ihm das dann bei zwei gleichzeitigen Zugriffen um die Ohren fliegt.

Es sieht nicht so aus als ob das ein Speicher-Problem ist, eher ein Konfigurationsproblem bei dem Platin-Paket.
Der Speicher bei dem Platin- und bei dem Pro-Paket sind gleich: 512 MB (memory_limit steht aber auf 256 MB).

Nur das Power Paket hat 1024 MB RAM zur Verfügung.

Bei der Installation von Contao über den Manager und anschließendem installieren von Erweiterungen hatte ich auch keine Problem - egal auf welchem Paket.
Die Probleme tauchten erst später auf...

Zitat:

---

Zitat von Spooky

Ah ok, ja kann schon sein :). Mit der Information kannst du ja nun wieder zum WebGo Support gehen.

---

Habe ich gerade gemacht und meine Erfahrungen an die per E-Mail geschickt.
Vielleicht finden die das Problem damit.

Das Problem ist ja eh schon gefunden ;). Die haben den für Prozesse deines Users zur Verfügung stehenden Speicher limitiert. Diese Limitation müsste WebGo entfernen oder erhöhen (bspw. auf 1536M).

Poste mal deine composer.json.

Zitat:

---

Zitat von Spooky

Poste mal deine composer.json.

---

Code:

---

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0+",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^5.6|^7.0",
        "codefog/contao-cookiebar": "^1.4",
        "codefog/contao-mobile_menu": "^2.7",
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4",
        "erdmannfreunde/onepage-navigation": "^1.0",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "roave/security-advisories": "dev-master",
        "terminal42/contao-easy_themes": "^2.2",
        "trilobit-gmbh/contao-cookiebar-bundle": "^1.0"
    },
    "config": {
        "component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

---

Das ist nun von dem Projekt das ich lokal aktualisiert habe und dann über das Terminal upgedatet habe.
Was hoffst du darin zu finden? Welche Erweiterungen installiert sind?

Zitat:

---

Zitat von Spooky

Das Problem ist ja eh schon gefunden ;). Die haben den für Prozesse deines Users zur Verfügung stehenden Speicher limitiert. Diese Limitation müsste WebGo entfernen oder erhöhen (bspw. auf 1536M).

---

Wie kommst du darauf?

Zitat:

---

Zitat von Cranker

Code:

---

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0+",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^5.6|^7.0",
        "codefog/contao-cookiebar": "^1.4",
        "codefog/contao-mobile_menu": "^2.7",
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4",
        "erdmannfreunde/onepage-navigation": "^1.0",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "roave/security-advisories": "dev-master",
        "terminal42/contao-easy_themes": "^2.2",
        "trilobit-gmbh/contao-cookiebar-bundle": "^1.0"
    },
    "config": {
        "component-dir": "assets"
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

---

Das ist nun von dem Projekt das ich lokal aktualisiert habe und dann über das Terminal upgedatet habe.
Was hoffst du darin zu finden? Welche Erweiterungen installiert sind?

---

Verwende diese composer.json und versuche es nochmal:

Code:

---

{
    "name": "contao/managed-edition",
    "type": "project",
    "description": "Contao Open Source CMS",
    "license": "LGPL-3.0-or-later",
    "authors": [
        {
            "name": "Leo Feyer",
            "homepage": "https://github.com/leofeyer"
        }
    ],
    "require": {
        "php": "^5.6|^7.0",
        "codefog/contao-cookiebar": "^1.4",
        "codefog/contao-mobile_menu": "^2.7",
        "contao/calendar-bundle": "^4.4",
        "contao/comments-bundle": "^4.4",
        "contao/faq-bundle": "^4.4",
        "contao/listing-bundle": "^4.4",
        "contao/manager-bundle": "4.4.*",
        "contao/news-bundle": "^4.4",
        "contao/newsletter-bundle": "^4.4",
        "erdmannfreunde/onepage-navigation": "^1.0",
        "madeyourday/contao-rocksolid-columns": "^2.0",
        "terminal42/contao-easy_themes": "^2.2",
        "trilobit-gmbh/contao-cookiebar-bundle": "^1.0"
    },
    "conflict": {
        "contao/core-bundle": "<4.4.8"
    },
    "config": {
        "component-dir": "assets"
    },
    "extra": {
        "branch-alias": {
            "dev-4.4": "4.4.x-dev"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ],
        "post-update-cmd": [
            "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication"
        ]
    }
}

---

Im wesentlichen habe ich "roave/security-advisories": "dev-master", entfernt - denn diese Abhängigkeit verbraucht bei der Abhängigkeitsauflösung viel mehr Speicher. Siehe https://community.contao.org/de/show...l=1#post466415

Zitat:

---

Zitat von Cranker

Wie kommst du darauf?

---

Das geht aus dieser Fehlermeldung hervor.

Man muss beim RAM unterscheiden zwischen Konsolenprozessen (Composer Konsolenaufruf), Apache-Prozessen und eventuell noch vom Apache-Prozess erzeugten Konsolenprozessen (Contao-Manager). Das kann alles unterschiedlich konfiguriert sein.
Das Platin-Paket ist auch kein CMS-Paket wie CMS Pro und CMS Power. Kann durchaus sein, dass hier für die CMS-Pakete eben andere Regeln gelten als für die "Go-Pakete" und vielleicht nochmal andere für die aktuellen Webhosting-Pakete (Starter, Profi, Business, Power). Es könnte also dem GoPaket Platin ohne Weiteres auf der Konsole oder über den Manager nur z.B. 512MB zugestanden werden und dem CMS Pro 1GB, obwohl bei beiden steht 512MB.

Zitat:

---

Zitat von Spooky

Verwende diese composer.json und versuche es nochmal:

---

Das hat leider nicht geklappt:

Code:

---

Using version ^1.0 for trilobit-gmbh/contao-cookiebar-bundle
/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

---

Zitat:

---

Zitat von Spooky

Im wesentlichen habe ich "roave/security-advisories": "dev-master", entfernt - denn diese Abhängigkeit verbraucht bei der Abhängigkeitsauflösung viel mehr Speicher. Siehe https://community.contao.org/de/show...l=1#post466415

---

Ah. Das hatte ich noch nicht gesehen.

Zitat:

---

Zitat von Spooky

Das geht aus dieser Fehlermeldung hervor.

---

O.K.

Irgendwas geht hier furchtbar schief. Ich teste gerade auf einem Platin-Paket, natürlich nur im ureigensten Interesse des entsprechenden Kunden, der ja auch mal Contao 4 bekommen soll. ;)

Ausgangslage: Alte Testinstallation 4.4.4 mit Manager Beta 10, nur Core installiert. Update mit dem alten Manager auf 4.4.16 problemlos.
Ich starte dann den Manager neu und er macht ein Update auf Beta 16. Ich wähle Webgo, alles ok.

Dann kommt der Teil, den ich nicht wirklich verstehe ...
1) Ich versuche die erste Erweiterung zu installieren (codefog/contao-cookiebar). Es kommt der obenstehende mmap-Fehler.
2) Ich klicke auf "Bestätigen und Schliessen", der Manager initialisiert sich offenbar neu und prüft das System und die Installation, danach erscheint die Suchmaske für die Erweiterungen und kreiselt endlos mit dem zuvor eingegebenen Suchstring.
6) Ich breche das ab durch Klick auf das Kreuz hinter dem Eingabefeld.
7) Es erscheint wieder die Liste der installierten Bundles, ich klicke auf "Pakete aktualisieren".
8) Nanu?!? Die zuvor nicht installierte Erweiterung wird problemlos installiert!
9) Installtool aufgerufen, danach im Manager "Bestätigen ud Schliessen".
10) Nächste Erweiterung, das selbe Spiel wieder, bei jeder Erweiterung.

Ich habe jetzt alles installiert aus der Liste von Cranker, bis auf das roave/security-advisories, das wird irgendwie nicht gefunden bei der Suche über den Manager. Dazu habe ich dann noch BackupDB installiert, auch hier das selbe Spiel, zuerst die mmap-Fehler Geschichte. Aber jetzt sind die Erweiterungen jedenfalls alle drin in der Installation. Ein oder zwei Mal wurde gemeckert, dass was mit der Installation nicht stimmt, irgendwelche Dateien gefunden wurden. Aktuelle Seite neu laden im Firefox hat jedes Mal zuverlässig geholfen, danach gings dann wieder weiter. Jetzt muss mir das nur noch jemand erklären...

Edit: Ich habe eben noch versucht, roave/security advisories zu installieren mit

Code:

---

php71 composer.phar require --dev roave/security-advisories:dev-master

---

Das ging dann schief:

Code:

---

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

mmap() failed: [12] Cannot allocate memory

mmap() failed: [12] Cannot allocate memory
PHP Fatal error:  Out of memory (allocated 1046487040) (tried to allocate 4096 bytes) in phar:///home/www/kundendomain.de/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Fatal error: Out of memory (allocated 1046487040) (tried to allocate 4096 bytes) in phar:///home/www/kundendomain.de/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

---

Man sieht aber zumindest, dass tatsächlich 1GB RAM verfügbar zu sein scheint im Platin-Paket.

Etwas änlich Seltsames habe ich auch gerade erlebt, als ich mit nem goPlatin von 4.4.14 auf 4.4.16 updaten wollte. Zuerst wollte sich der Manager auf 16 beta aktualisieren. In der Konsole erschien nichts, die Sanduhr lief ewig. Irgendwann habe ich einfach die contao-manager.phar.php neu aufgerufen, und siehe da, das Update auf die beta 16 schien erfolgreich funktioniert zu haben, obwohl keine Ausgabe im console DIV zu sehen war und die Sanduhr ewig lief.

Dann die Pakete aktualisiert, wollte ja von 4.4.14 auf 4.4.16, und dort gleiches Spiel mit Consolen-DIV und Sanduhr erlebt. Irgendwann dann wieder contao-manager.phar.php aufgerufen und dann die Ausgabe in der Konsole gesehen. Alles schien erfolgreich verlaufen zu sein.

Aber dass da keine Ausgabe in der Konsole kommt und die Sanduhr ewig läuft, kann ja eigentlich nicht am Server liegen, sondern an dem Manager denke ich.

Ich verknüpfe das hier mal mit den Meldungen zum Hoster WebHostOne. Auch dort scheinen sich Hinweise zu verdichten, dass es was mit der neuen Version des Managers zu tun haben könnte: https://community.contao.org/de/showthread.php?70192-Contao-Manager-Webhostone-Cannot-allocate-memory

Ich will nur kurz bestätigen, dass ich mit meinem Platin Paket genau die gleichen Probleme habe, die hier beschrieben wurden.
Mein Vorgehen ist auch immer die Zwei-Schritte Taktik: Erweiterung über Manager installieren bis zur genannten Fehlermeldung, dann install oder update über die Konsole.


Gesendet von iPad mit Tapatalk

habe die Probleme mal an Andi (CM-Hauptentwickler) weitergeleitet.

Was ich halt gar nicht verstehen kann ist, dass beim ersten Aufruf des Composer Update durch den Manager regelmäßig zu 100% der mmap-Fehler kommt und beim zweiten Versuch dann aber das Memory reicht. Jedenfalls etwa bis zu der Anzahl und Größe von Erweiterungen, wie ich es auch anfangs bei älteren Managerversionen gewohnt war. Dass das mit roave/security-advisories in Entwicklerversion nicht mehr klappt finde ich absolut nachvollziehbar. Das scheint also real zu sein. Aber was passiert da beim ersten Aufruf? Was ist da anders? Wird da mehr RAM allokiert, ist da vor dem Aufruf bereits mehr RAM allokiert oder ist es vielleicht gar nicht die Menge des angeforderten RAM was die Probleme macht, sondern irgendetwas Anderes? Jedenfalls behauptet das Konsolenfenster auch beim zweiten Versuch "Updating dependencies" und es klappt.

Ich kann mich hier anschließen.
Ich bin schon seit Januar mit Webgo (Herrn da Silva) im Kontakt. Leider bin ich von den Antworten nicht ganz so begeistert.
Die letzte Antwort kam heute und zwar nicht zum ersten Mal mit der Auskunft, dass bei ihnen angeblich der Konsolenbefehl fürs Update beim Testen funktioniert hat.
Mir ist das seit dem ersten Auftreten der Probleme noch nie gelungen. Ich kann mir irgenwie keinen Reim drauf machen was das soll.
Ich kann nicht bestätigen, dass es grundsätzlich die Platinpakete betrifft.

Platinpakete bei folgenden Servern laufen problemlos:
s139
s133
s93

Paket cms Pro auf folgendem Serverläuft ebenfalls problemlos:
s143

Probleme macht das Platin-Paket auf Server:
s86

Die Installationen sind alle vergleichbar - kleine Websites mit nur sehr wenig Erweiterungen.
Bei mir ist das Problem zum ersten Mal im Januar auf der Konsole aufgetreten.
Zuvor war sowohl Installation über den Manager als auch Installation über die Konsole immer problemlos möglich.

Ich kann nicht mal eine blanke Contao Core Testversion aktualisieren (weder über Konsole noch über Contao Manager).

Ich frag mich auch langsam was da los ist.

Vielleicht noch zur Ergänzung: Verwendet wir entweder PHP 7.1 oder 7.2.

Ich hatte mir in den funktionierenden Paketen auch mal den Speicherbedarf angeschaut:

Der durchschnittlichen Speicherbedarf lag bei ca. 270MB (peak: zwischen 800MB und 900MB), time: zwischen 60s und 75s. Aber wie gesagt waren das Installationen mit teilweise mehrere Erweiterungen, während die nicht funktionierende Testversion völlig „nackt“ ist und damit sicher nicht mehr Speicher benötigt.

Moin,

wir haben Eure Posts aufmerksam durch gelesen und sind dabei einige Neuerungen durchzuführen. So konnten wir das SSL Problem mittlerweile beheben.

Das hier erwähnte Problem bei Platin Tarifen konnten wir bisher jedoch mittels interner Tests nicht nachstellen, da diese Problematik nur sporadisch vorzukommen scheint. Wir bitten Euch uns bei Problemen an unsere E-Mailadresse support@webgo.de eine Nachricht zu schicken. Im ersten Satz der Mail schreibt bitte "z. Hd. Herrn Möhring - Contao Platinpaket". Wir werden uns dann mit Euch schnellst möglich in Verbindung setzen um das Problem langfristig zu beseitigen.

Beste Grüße

Euer webgo Team

Hallo in die Runde,

nachdem ich in den letzten Wochen wirklich nur noch genervt war, weil meine Tickets meist sehr unzureichend beantwortet worden sind, habe ich kurzer Hand das Paket gewechselt (steht nicht auf der "normalen" Paketseite: https://www.webgo.de/cms/pakete/ Hier das Power-Paket).
Jetzt flutscht alles (nachdem es noch Probleme mit dem Zertifikat gab, die aber mittlerweile auch behoben wurden.)

Viele Grüße
Hella

Zitat:

---

Zitat von tab

Was ich halt gar nicht verstehen kann ist, dass beim ersten Aufruf des Composer Update durch den Manager regelmäßig zu 100% der mmap-Fehler kommt und beim zweiten Versuch dann aber das Memory reicht.

---

Hmm, jetzt führe ich schon Selbstgespräche. Übers Wochenende werde ich versuchen, das alles nochmals sauber nachzuvollziehen und dabei alle durchgeführten Schritte mitprotokollieren. In der Hoffnung, dass es den Manager-Entwicklern und/oder Webgo weiterhilft. Eventuell kann ich den Kunden, dem das Platin-Paket gehört, dann auch davon überzeugen, Entwicklern und/oder Webgo offiziell Zugriff auf die Testinstallation zu gewähren.

Ein Ansatz für eine mögliche Erklärung für den Unterschied zwischen gescheitertem ersten und erfolgreichem zweiten Versuch, die Abhängigkeiten aufzulösen, wäre eventuell auch, dass nach der Auswahl der Erweiterung vermutlich ein "composer require" durchgeführt werden soll und später die erfolgreiche Installation mit einem "composer update" erfolgt. Trotz mmap-Fehler scheint die Erweiterung wohl zumindest in die composer.json eingetragen zu werden, so dass hinterher das Update die Erweiterung installiert. Muss ich aber auch noch überprüfen, also wie die composer.json vor und nach dem gescheiterten Installationsversuch aussieht. Weiterhin auch, wie sich das mit composer require und composer update direkt in der Konsole verhält. Interessant wäre auch, ob es bei diesem Paket mit dem aktuellen Manager ebenfalls Probleme beim Update einer völlig neuen Core-Testinstallation gibt wie von @mlweb beschrieben. Denn das erfolgreiche Contao-Update von 4.4.4 auf 4.4.16 habe ich ja mit der alten Manager-Version Beta 10 durchgeführt und nicht mit der aktuellen Version.

Ich habe nach dem ersten Scheitern und bei allen weiteren Test, die ich zusammen mit Webgo (Mitarbeiter von Webgo hatte vollen Zugang zu diesem Account) durchgeführt habe nur auf der Konsole gearbeitet. Die letzte Stand ist: Ich werde mit diesem Paket auf einen anderen Server umziehen. Die Ursache für das Verhalten konnte man leider nicht finden.

Das heißt, das Problem war identisch mit Manager oder direkt in der Konsole?

Ja. Ind es war zuerst auch eine ältere Version des Managers. Erst bei den letzten Tests war es die neueste. Erstmalig aufgetreten nach einer Serverwartung bei Webgo.
Ich glaub da noch immer an einen Zusammenhang ;).

Ja, ein Zusammenhang ist natürlich gut möglich. Was heißen kann, aber nicht muss, dass eine Fehlkonfiguration seitens Webgo vorliegt. Kann also auch sein, dass durch die Serverwartung etwas geändert wurde und dadurch jetzt ein Fehler in Composer oder PHP schlimmere Auswirkungen hat. Natürlich wird da jetzt ganz pragmatisch eine passende Konfiguration gefunden werden müssen, damit das nicht mehr so ist. Egal ob der Fehler bei Webgo liegt oder anderswo. Die Hoffnung, dass ein möglicher Fehler in PHP, der sich bereits durch mehrere PHP-Versionen durchzieht, jetzt kurzfristig gefunden und behoben wird, halte ich nicht für besonders realistisch.

Edit: Den Kunden umzuziehen wäre für mich mit mehr Schmerzen verbunden als der augenblickliche Zustand. Es ändern sich dadurch zuallermindest wieder die IMAP/SMTP-Server bei den Email-Accounts, während der Kunde bisher noch gar kein Contao 4 hat und ich mit dem Istzustand notfalls sogar leben könnte. Ich bekomme ja letztlich trotz des Fehlers alles installiert was ich brauche - oder zumindest auch nicht weniger als ohne den Fehler - auch wenn es umständlicher ist als es sein sollte.

Zitat:

---

Zitat von mlweb

Ja. Ind es war zuerst auch eine ältere Version des Managers. Erst bei den letzten Tests war es die neueste. Erstmalig aufgetreten nach einer Serverwartung bei Webgo.
Ich glaub da noch immer an einen Zusammenhang ;).

---

Bei Webhostone ist ja das gleiche Problem aufgetreten, dann müsste es dort ja auch an der Serverwartung liegen!? Und bei den anderen Providern taucht das Problem nicht auf, weil die gleich mehr Arbeitsspeicher zur Verfügung stellen?! Jedenfalls gibt es bei dem 512 MB-Arbeitsspeicher-Paket bei Webhostone keine Probleme.

Das GoPaket Platin hat 512 MB.

Hat von euch irgendjemand schon den Tipp aus Post 199
https://community.contao.org/de/show...l=1#post468020
vom WebGo Mitarbeiter probiert und Erfolg gehabt?

Gruß
Thomas

Ich nicht, weil mir Herr da Silva zur gleichen Zeit einen Serverwechsel angeboten hat. Das werde ich dann heute oder morgen vorbereiten.

Ich probiers grade mal... und berichte.