Composer RAM-Fresser

[BugBuster]

Ich bin erstaunt, dass das bei uberspace funktioniert:

[9.1MB/0.13s] Loading composer repositories with package information
[9.5MB/0.38s] Updating dependencies (including require-dev)
[566.6MB/28.96s]   - Removing bugbuster/integrity_check (3.5.14)
[566.6MB/29.03s]   - Installing bugbuster/integrity_check (3.5.15)
[566.8MB/29.03s]     Downloading
[566.9MB/31.07s] 
[566.9MB/31.18s]   - installed 52 files
[191.3MB/33.27s] Writing lock file
[191.3MB/33.27s] Generating autoload files
[191.5MB/34.86s] Runonce created with 1 updates
[191.5MB/34.86s] Clean contao internal config cache
[191.5MB/34.92s] Clean contao internal dca cache
[191.5MB/34.98s] Clean contao internal language cache
[191.5MB/35.03s] Clean contao internal sql cache
[191.9MB/35.28s] Memory usage: 191.92MB (peak: 567.98MB), time: 35.28s

566MB um eine Erweiterung zu aktualisieren? Ja, ich weiß, der prüft auch alle anderen Pakete und Abhängigkeiten.
Aber meine Güte, vor einem Monat waren es noch ~200 MB, das wird ja immer mehr, ohne das ich weitere Erweiterungen installiert habe.

Langsam tendiere ich auch zu der Meinung: "Das kannste schon so machen, aber dann isses halt kacke...".

[Spooky]

Manchmal geht das auch über 1GiB, wenn Symfony involviert ist.

[tab]

Grauenhaft. Aber ich denke mal, das Problem ist bekannt und es wird bestimmt bereits an praktikablen Lösungen gearbeitet. Composer mit einem derartigen RAM-Verbrauch auf dem Webserver laufen zu lassen, ist jedenfalls keine. Oder sie beschränkt jedenfalls die Verwendbarkeit von Contao dramatisch, indem sie sehr hohe Anforderungen an den Webserver/Webspace stellt. Und spätestens wenn Symfony ins Spiel kommt, gibt es für die denkbaren Anforderungen mit der momentanen Lösung keine obere Grenze. Die können morgen oder übermorgen auch bei 16GB liegen, oder 128GB, oder ... Da kann dann theoretisch sehr schnell auch der Desktop-Rechner mal nicht mehr reichen, um das Optimierungsproblem zu lösen.

[Contao-Academy]

Der RAM-Verbrauch ist ein echtes Problem bei vielen Hostings. Ich hoffe auch, dass es hierfür irgendwie eine Lösung gibt. Manchmal hilft es, wenn man unter Einstellungen die "Minimale Stabilität" auf "Stabil" umstellt. Kommt halt auch drauf an, welche Erweiterungen man einsetzt.

[Webstylerin]

Ich muss mir jetzt hier auch mal etwas Luft machen, der Speicherverbrauch ist echt nicht mehr feierlich.

Gerade mache ich an einer Seite weiter, die Anfang des Jahres aufgesetzt wurde und nun endlich weiter gehen kann. Also als erstes mal Contao und Erweiterungen aktualisieren und schwupps, Composer macht mir einen Strich durch die Rechnung.

Die Seite liegt auf einem Entwicklungsserver eines meiner Kunden der bisher mit dem Composer keine Probleme hatte. Das ist jetzt wohl vorbei, denn jetzt reicht ihm der Speicher nicht mehr. Minimale Stabilität steht auf "Stabil"!

Ich werd demnächst mal meine Standarderweiterungen durch gehen und schauen, ob ich die alle noch im ER2 finde, langsam reichts nämlich. Entweder das Ding haut mir eine Fehlermeldung nach der anderen um die Ohren oder der Speicher reicht nicht. Ganz besonders lustig, wenn es lange ging und auf einmal reichts nicht mehr.

Die Idee vom Composer ist super, aber die Wirklichkeit eher die Hölle.

Sorry für den Jammerthread, aber es vergeht fast kein Tag an dem der Composer in irgendeiner Installation nicht rum zickt.

[Spooky]

Wir haben letztens ein neues Symfony Projekt aufgesetzt (nichts mit Contao). Da reichte auch 1G nicht mehr . // oops, schon gepostet

[mandrael]

Hallo! Ich mache gerade ein Upgrade einer Seite von Contao v2 auf v3.5 und überlege, Composer statt ER2 einzusetzen. Etliche Erweiterungen scheinen ja nur mehr dort vorzufinden zu sein. Zb. martin-kozianka/contao-fullcalendar , der gut ics einbinden kann. Ich habe gerade eine Testinstallation mit Composer am Laufen und frage mich, ob ich ihn nun einsetzen soll oder nicht. Was man hier so alles über RAM-Probleme liest, ist wirklich bedenklich. Mit Standardeinstellungen bekomme ich auch die Fehlermeldung "Fatal error: Out of memory (allocated 423362560)" - wenn ich "ab Alpha" einstelle, geht es mit den paar Erweiterungen, die derzeit drauf sind.
Contao läuft schon Jahre auf df und wir sind recht zufrieden; die bieten aber im Webhosting auch auf Nachfrage maximal 256Mb an. So wie ich das sehe, müsste ich das ganze Web wegen Composer auf einen anderen Anbieter übertragen, zB Webgo, nur um Composer (vielleicht stabil) nutzen zu können? Ich habe nirgends Systemanforderungen für Contao 3.5 mit Composer gesehen; kann man sagen, ab welcher Hauptspeichergröße der Composer zuverlässig läuft?
lg Michael

[Spooky]

kann man sagen, ab welcher Hauptspeichergröße der Composer zuverlässig läuft?

Das kann man nicht sagen, weil das auf die composer Operation ankommt. Wenn composer komplexe oder viele Abhängigkeiten (oder beides) auflösen musst, steigt der Speicherverbrauch. Man kann keine Aussage treffen wie zB "Mit 1GiB RAM hast du sicher immer genug". Darüberhinaus brauchst du diese Menge an Arbeitsspeicher ja nicht für den Betrieb der Website, sondern nur für die composer operationen - welche besser über die command line ausgeführt werden sollten. Dort hast du meistens (vorsicht, auch hier nicht immer) kein spezifisches memory limit, oder ein sehr großes.

[css-umsetzung]

Wir haben letztens ein neues Symfony Projekt aufgesetzt (nichts mit Contao). Da reichte auch 1G nicht mehr . // oops, schon gepostet

Das ist doch aber echt Krank oder? Denn das bedeutet das ich die Seiten zum updaten auf meinen Server holen und sie danach zurück schieben muss, was ja mal zu 90% nicht so einfach geht weil die symlinks stress machen.

Kein normaler webspace bekommt von seinem Anbieter 1,5G

Ich verstehe wirklich nicht, wie sich so etwas mit diesen Anforderungen so durchsetzen kann.

Ein Hoch auf das können der composer Entwickler die hier so, mit den nicht vorhandenen Ressourcen rumschlampen.

[Spooky]

Das ist doch aber echt Krank oder? Denn das bedeutet das ich die Seiten zum updaten auf meinen Server holen und sie danach zurück schieben muss, was ja mal zu 90% nicht so einfach geht weil die symlinks stress machen.

Bei Symfony Projekten haben wir das immer schon so gemacht. Primär aber eigentlich deswegen, weil wir nicht bei jedem Server auch SSH Zugriff hatten.

[Zwergenmeister]

Der Composer macht von Anfang an nur Ärger und nervt bei jedem update ! Fehler, Fehler Fehler, mehr Speicher, Speicher, Speicher

Habe nach 1,5 Jahren auch langsam genug und wechsel wieder zu ER2 oder muss bald alternativen zu Contao suchen.

[css-umsetzung]

Ja, leider ist das so

Ich habe noch keine contao Installation gesehen die den composer hat und dauerhaft fehlerfrei arbeitet.

[mandrael]

Hmm, ich habe nun die neue Contao3-Seite mit dem ER2 umgesetzt und sie läuft wunderbar (wenn ER2 auch nicht alle Updates in der Liste anzeigte und ich manuell durchklicken und auf installieren klicken musste). Ich bin immer für Neues zu haben und experimentierfreudig, aber es müsste klare Vorteile bringen. Ich habe auch ein paar kommerzielle Erweiterungen verwendet, was Composer noch nicht unterstützen soll (Lizenzschlüssel). Na, ich bin gespannt auf die ck2017. Contao ist ja ganz fantastisch und verdient eine Erweiterungsverwaltung aus einem Guss, mit denen sowohl Entwickler als auch Anwender glücklich sind, und die vor allem nicht Anforderungen stellt, die nur ein dedicated server erfüllt.

Gesendet von meinem SM-N910F mit Tapatalk

[BugBuster]

Der Composer macht von Anfang an nur Ärger und nervt bei jedem update ! Fehler, Fehler Fehler, mehr Speicher, Speicher, Speicher

Konnte ich bei mir abstellen, nachdem ich in System -> Einstellungen den Composer bei "Ausführungsmodus" umgestellt habe von "während der aktuellen HTTP Anfrage" auf "als Unterprozess des aktuellen Webprozesses". Der Befehl steht bei mir derzeit so:

/usr/bin/env php -d memory_limit=1G -d max_execution_time=900

Dort bekomme ich, zumindest bei meinem Hoster, mehr RAM als im laufendem PHP Prozess.

[FloB]

Vielleicht könnte man mit Weiterleitungen/iFrames/AJAX und ein Aufsplitten der Composer-Prozesse es schaffen ein bisschen mehr Ressourcen für den Composer rauszuschlagen? Contao selber verschlingt ja auch RAM. Möglicherweise könnten einige davon profitieren (die von der Einstellung nix wissen bzw. keine Konsolenbefehle via PHP schicken dürfen), wenn man ein minimales standalone Script für jeden einzelnen Ressourcen-intensiven Composer-Schritt hat?

Die genannte Backend-Einstellung sollte auch besser automatisch gesetzt/gecheckt werden, je nachdem, was der Server grade so hergibt … macht es einfacher für den gemeinen (und auch Profi-)Anwender.

[Spooky]

Es ist ja nur ein einzelner Prozess, den kannst du ja nicht aufteilen. Das müsste man wenn dann direkt im composer implementieren.

Und da wäre wahrscheinlich ein optionaler out-of-core Modus die bessere Alternative.

[FloB]

Es ist ja nur ein einzelner Prozess, den kannst du ja nicht aufteilen. Das müsste man wenn dann direkt im composer implementieren.

Aber der Prozess lässt sich ja doch in einzelne Teilschritte zerteilen, oder? Also information gathering, SAT solving, package download & upgrade … Genau das jeweils in separate minimale PHP-Prozesse auslagern (wie gesagt minimales Wrapper-Script per JS / iframe mit HTTP-Redirect aufrufen), um für jeden Teilschritt jeweils das Maximum an RAM zur Verfügung zu haben.

[Spooky]

Ich denke mal, dass das SAT solving alleine schon den größen Anteil ausmacht und das daher nichts bringen wird.

[chrischnian]

Also ich mach mir auch immer mehr sorgen um die ganze Sache.

Der Witz ist das man zuerst alles installieren kann und dann nach x Wochen wird ein Update gemeldet und man will dabei auch die Packages aktualisieren und dann hängt man fest.
Wir haben schon DF genutzt dort hatten wir zum Glück ein Paket mit SSH und per SSH hat man mehr Ressourcen als über den Browser somit konnte man oft doch updaten.

Seit einiger Zeit nutze ich nur noch die VServer von NetCup und dort habe ich 6GB RAM und kann es mir nun einstellen. Dennoch bin ich mit der Entwicklung sehr unzufrieden und bin am Alternativen suchen.

Will ja net jeden Kunden für eine "10 Seiten Webseite" einen VServer andrehen um den Composer zufriedenzustellen. Von der Wartung gar nicht zu sprechen.

Wenn man aber sich mal an das Konzept der Inhalte gewöhnt hat dann will man es eigentlich nicht mehr missen. Naja schauen wir mal ob man eine Alternative findet oder ob es wieder besser wird, wobei da zweifel ich dran wenn man die letzten 2 Jahre so sieht.

[FloB]

Ich denke mal, dass das SAT solving alleine schon den größen Anteil ausmacht und das daher nichts bringen wird.

Dann wird es ja schon reichen ausschließlich diesen Prozessschritt in eine minimale Umgebung auszulagern. Das entspräche ja auch der Lösung mit einem externen Solver-Server, nur dass der Schritt halt nicht extern ausgeführt wird, sondern in einem miminmalen PHP-Prozess auf dem Server. Dieser kann ja – je nach verfügbaren Funktionen – automatisch entweder per System-Befehl standalone oder per Web Request (also via JS oder iframe) aufgerufen werden. Wichtig ist ja nur, dass für den resourcen-intensivsten Schritt das Maximum an Resourcen zur Verfügung steht, also nichts geladen wird, was nicht absolut für diesen Schritt nötig ist.

[Spooky]

Dann kannst du dir aber auch gleich einfach das composer.lock file für deine composer.json auf einem anderen Server erzeugen lassen und dann auf dem Zielserver mit composer install verwenden . Das ist weniger kompliziert als irgendwie zu versuchen die composer Prozesse aufzuteilen.

[FloB]

Dann kannst du dir aber auch gleich einfach das composer.lock file für deine composer.json auf einem anderen Server erzeugen lassen und dann auf dem Zielserver mit composer install verwenden . Das ist weniger kompliziert als irgendwie zu versuchen die composer Prozesse aufzuteilen.

Es geht ja darum es für den einfachen Fall für den Anwender so umstandslos wie möglich zu machen. Und damit die dauerhaften Klagen über die Unbenutzbarkeit des Composers zu reduzieren. Selbstverständlich kann man auch die Staging-Geschichte machen, das ist aber bei vielen Projekten einfach nicht nötig oder unrealistisch. Alle profitieren davon, wenn das System versucht so klug wie möglich zu sein und dem Anwender damit so viel Arbeit wie möglich abnimmt (aber trotzdem fortgeschrittenere Methoden zulässt, sofern diese gewünscht sind).

[Spooky]

Das kann ja auch automatisch passieren. Wenn man auf "Pakete aktualisieren" klickt, wird die composer.json + die Platform Information an den "composer server" geschickt, der erzeugt die composer.json und gibt diese zurück und der composer-client führt dann automatisch composer install aus. Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time.

Das wurde ja woanders schon mal besprochen.

[FloB]

Das kann ja auch automatisch passieren. Wenn man auf "Pakete aktualisieren" klickt, wird die composer.json + die Platform Information an den "composer server" geschickt, der erzeugt die composer.json und gibt diese zurück und der composer-client führt dann automatisch composer install aus. Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time.

Das wurde ja woanders schon mal besprochen.

Ja, Toflar hat da an was gebastelt. Spielt aber keine Rolle. Es gibt aber bisher keinen öffentlichen Server dafür, und selbst wenn es einen gibt, wird dieser sich offensichtlich nicht kostenlos betreiben lassen. Und obwohl ich mit Freude für das LiveUpdate zahle (obwohl ich es vergleichsweise selten nutze und es kostenlose Alternativen gibt), sehe ich nicht ein, warum jetzt einige für einen Resolve zahlen sollten, nur weil sie eine Mini-Website mit Contao betreiben.

Egal ob der Resolve jetzt auf einem externen oder dem selben Server ausgeführt wird, klar ist, dass man mit dem Heraustrennen der kritischen Prozesse viele Beschwerden gegenüber Composer lösen kann. Die (lokale) SAT-Auflösung in einem minimalen PHP-Prozess wäre ein erster Schritt, der auch den Weg zu einem externen Resolve-Server ebnen kann, wenn dieser jemals eingerichtet wird. Fakt ist, dass man bereits jetzt schon was tun kann, was nicht allzu kompliziert sein sollte und Einigen helfen kann.

[Spooky]

Mein Punkt war aber, dass das meiner Meinung nach nichts bringen wird. Selbst wenn du das resolving irgendwie trennst aber dennoch lokal am selben Server mit den selben Speicherlimitationen laufen lässt, wird der Speicher evt. nicht reichen - eben weil das der aufwändigste Prozess ist.

[xtra]

Ja, Toflar hat da an was gebastelt. Spielt aber keine Rolle. Es gibt aber bisher keinen öffentlichen Server dafür, und selbst wenn es einen gibt, wird dieser sich offensichtlich nicht kostenlos betreiben lassen. Und obwohl ich mit Freude für das LiveUpdate zahle (obwohl ich es vergleichsweise selten nutze und es kostenlose Alternativen gibt), sehe ich nicht ein, warum jetzt einige für einen Resolve zahlen sollten, nur weil sie eine Mini-Website mit Contao betreiben.

Ich sehe dann in Zukunft auch nicht ein, dass ich yberhaupt an kleine Hoster denken sollte und obendrein sehe ich auch nicht mehr ein warum ich kostenlos yberhaupt was zur Verfygung stellen sollte, bloss weil kleine Seiten das auch brauchen koennten. *scnr* *kopfschyttelnd*

Sorry, aber bei so formulierten postings bin ich leicht pissed... bin ich von Dir aber zum Glyck anders gewoehnt und kann ich als Ausrutscher werten.

Egal ob der Resolve jetzt auf einem externen oder dem selben Server ausgeführt wird, klar ist, dass man mit dem Heraustrennen der kritischen Prozesse viele Beschwerden gegenüber Composer lösen kann. Die (lokale) SAT-Auflösung in einem minimalen PHP-Prozess wäre ein erster Schritt, der auch den Weg zu einem externen Resolve-Server ebnen kann, wenn dieser jemals eingerichtet wird. Fakt ist, dass man bereits jetzt schon was tun kann, was nicht allzu kompliziert sein sollte und Einigen helfen kann.

Der kritische Prozess IST bereits herausgeloest und frisst genau soviel RAM wie er eben braucht.
Besser wird es erst mit composer 2.0, welcher noch laenger brauchen wird, weil da dann die Internas von Composer anders gebaut sein werden (gibt dazu einen PR, den such ich aber nun nicht kostenlos raus, nichtmal fyr grosse Webseiten).

[FloB]

Ich sehe dann in Zukunft auch nicht ein, dass ich yberhaupt an kleine Hoster denken sollte und obendrein sehe ich auch nicht mehr ein warum ich kostenlos yberhaupt was zur Verfygung stellen sollte, bloss weil kleine Seiten das auch brauchen koennten. *scnr* *kopfschyttelnd*

Sorry, ich wollte damit keine ich-will-alles-kostenlos-Aktion starten oder gar fordern. Mein Punkt war ja, dass das gar nicht kostenlos geht (und das auch recht so ist). War leicht anders zu verstehen, tut mir Leid.

Allerdings ist ein Auflösen der Abhängigkeiten (rechenintensiv, unregelmäßig und unplanbar) ein ganz anderes Kaliber als alle paar Wochen/Monate ein System-Update einzuspielen (datenintensiv, regelmäßig und gut planbar), dementsprechend mit anderen Anforderungen verknüpft – und nach meiner Einschätzung mit ganz anderen Kosten und Kostenstrukturen verbunden. Damit (und vielen anderen Gründen) macht es aus vielerlei Sicht keinen Sinn Kleinst-Projekte (die entsprechend auch geringste Hosting-Anforderungen besitzen und damit überproportional von der Problematik betroffen sind) zur Kasse zu bitten – ob jetzt durch einen Resolver-Service oder fetteres Hosting oder mehr Administrationsaufwand und Komplexität durch Staging. Es muss also darum gehen die Auswirkungen auf diejenigen Betroffenen[1] bestmöglich abzumildern, z. B. mit der von mir beschriebenen Maßnahme.

[1] Ich möchte nochmal betonen, dass ich nicht zu diesen "Betroffenen" gehöre, mein Server hat mehr als ausreichend Reserven für selbst komplexe Probleme – I've got no horse in this race, wie der Brite so schön sagt, außer dass das Thema Contao als Ganzes betrifft.

Der kritische Prozess IST bereits herausgeloest und frisst genau soviel RAM wie er eben braucht.

Das ist gut zu hören. Darf ich fragen, wie das konkret in Contao umgesetzt wurde? Ich verheddere mich grade im Sammelsurium der Pakete und komme da nicht weiter.
Nur zum Klarstellen, ich stelle mir den minimalen Prozess bzw. das auszuführende Skript in etwa so vor (Pseudocode – ohne die API oder inneren Vorgänge von Composer zu kennen!):

// Pseudo-Code!

include('Composer.phar');
$c = new Composer('composer.json');

// Die Daten zur Umgebung wurden bereits vorher gesammelt und werden jetzt nur noch eingelesen.
$env_data = file_get_contents('composer-env.json');

// SAT-Solver aufrufen.
$result_lock_data = $c->resolveDependenciesWith($env_data);

// Der nächste Schritt (separater Prozess) nutzt dann dieses Ergebnis.
file_put_contents('composer.lock', $result); 

Das ganze mit abgeleiteten Klassen o.Ä. zu machen wäre natürlich schöner, kostet aber einen Haufen Speicher.

Besser wird es erst mit composer 2.0, welcher noch laenger brauchen wird, weil da dann die Internas von Composer anders gebaut sein werden (gibt dazu einen PR, den such ich aber nun nicht kostenlos raus, nichtmal fyr grosse Webseiten).

Das ist noch viel besser zu hören, hilft aber (wegen der angesprochenen Umsetzungsdauer) auf absehbare Zeit leider nicht.

Problem ist: wenn das in einem Zug passieren soll, braucht man auch wiederum eine entsprechend lange max_execution_time

Darauf hatte ich noch vergessen einzugehen: Angenommen, der reine Solving-Prozess ist mit der max_execution_time abgedeckt, muss dein aufrufendes Skript nicht Solving-Dauer + x lang laufen, Stichwort polling (eben via Redirect bzw. JS).

[xtra]

Nur zum Klarstellen, ich stelle mir den minimalen Prozess bzw. das auszuführende Skript in etwa so vor (Pseudocode – ohne die API oder inneren Vorgänge von Composer zu kennen!):

In Pseudo code laeuft es in etwa so ab:

include('Composer.phar');
$c = new Composer('composer.json');
// Die Daten zur Umgebung wurden bereits vorher gesammelt und werden jetzt nur noch eingelesen.
$env_data = file_get_contents('installed.json');
$env_data = file_get_contents('package*.json'); // wobei package* irgend ein referenziertes package im tree ist.
// HIER MACHT ES BEI VIELEN SCHON BUMM, einfach weil der Baum zu gross ist!

// SAT-Solver aufrufen.
$result_lock_data = $c->resolveDependenciesWith($env_data); // HIER MACHT ES BEI DEN MEISTEN DANN ENDGUELTIG BUMM!
// Der nächste Schritt nutzt dann dieses Ergebnis zur installation...
$c->install($result); // Wer bis hier hin kommt, hat kein Problem mehr.
// ...und dumped dann.
file_put_contents('composer.lock', $result); 

[rezico]

Das ist echt Müll.
80% der Websites kann ich nicht mehr updaten, da sich wie gesagt kein Kunde einen VServer für eine 10 Seiten Website mit Kontaktformular und bisschen Schnickschnack holt...für ein vielfaches sollte man vielleicht dazu sagen.

Bei HostEurope müsste ich nun z. B. für 256 MB (die sowieso nicht ausreichen) das 5x vom jetzigen Preis bezahlen, das heißt faktisch kann man eine Website mit Composer dort nicht mehr hosten und müsste umgezogen werden...

Ich weiß dass das nicht mit Contao zusammenhängt sondern ausschließlich mit dem Composer - aber wie geht ihr nun damit um? Was sagt ihr euerm Kunden? Gibts Workarounds? (Ich hab hier alle besprochenen schon versucht,...nur stabile Versionen, nur die Quellen die man auch updaten will in der config lassen, auf HTTP umstellen... bringt alles nix!)

Bin gespannt auf Antworten, ich weiß dass ihr da tolle Arbeit leistet und geleistet habt aber so kann man das Teil LEIDER meines Erachtens absolut in die Tonne treten.

Danke schon einmal und viele Grüße,

Christian

[Spooky]

aber wie geht ihr nun damit um?

• Den detached mode verwenden.
• Wenn der detached mode aus irgendeinem Grund nicht funktioniet, dann per SSH auf die Konsole verbinden und das composer update manuell durchführen.
• Wenn kein SSH Zugang besteht, manuell deployen.

[rezico]

Hey Spooky,
danke für deine Antwort!

Kurz zu deinen Punkten:

der detatched-mode: ich denke dass heißt composer als eigenständigen Prozess verwenden in den Einstellungen auswählen?
Bringt bei mir leider nur:

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file: Permission denied
Failed to start up concurrent users module!

SSH gibts natürlich auf den wenigsten Standardhostings, in den meisten Fällen die mir bekannt sind kann ich bei nem SSH Zugang auch direkt die Einstellungen vornehmen die ich vornehmen muss....

Was mich jetzt aber am meisten interessiert: Was meinst du mit manuell deployen? Wie kann man sich das vorstellen?

DANKE!

Viele Grüße

Christian

[lucina]

Ich versteh's immer noch nicht - die 80% meiner betreuten Webseiten laufen 1a rauf mit Sternchen im zweitgünstigsten Paket des Feld-Wald-und Wiesen-Hosters Domainfactory. Mit Composer. Mit 128 MB RAM.

Die Projekte, bei denen es auf mehr ankommt und bei denen ich teilweise heftigst Entwicklerfunktionen benötige laufen da nicht, sind da auch noch nie gelaufen und werden auch nie in einem Shared-Hosting landen.

Ich persönlich denke, dass Webhoster ihre Hausaufgaben machen sollten. Das kommuniziere ich auch dem Kunden, und ich hatte gerade heute vormittag wieder einen Fall, bei dem der Kunde neben mir sass und den Unterschied zwischen den Firmen aus Montabaur, Karlsruhe, etc. und Qualitätshosting mitbekommen hat. Der war ganz erstaunt, dass sein System nach 20 Minuten lief, dass ich zwischendrin mit dem Support twitterte, der eine Funktion im relaunchten Backend versteckt hatte und er nun nicht einen halben Tag an mich bezahlen musste sondern nur eine halbe Stunde.

Just my 2 cents.

[Spooky]

Bringt bei mir leider nur:

$ /usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file:  Permission denied
Failed to start up concurrent users module!

Damit könntest du mal bei deinem Hoster nachfragen, warum das so ist. Also im genauen: warum der php Prozess, wenn man ihn mit shell_exec ausführt, nicht genügend Rechte hat. Im genauen lautet der Aufruf dann zB:

shell_exec('/usr/bin/env php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile') 

(im Ordner /composer deiner Contao Installation).

Versuche mal das /usr/bin/env zu entfernen, vielleicht liegt es daran. Das genaue Kommando muss ggf. je nach Umgebung immer angepasst werden.

Was mich jetzt aber am meisten interessiert: Was meinst du mit manuell deployen? Wie kann man sich das vorstellen?

Die Website bspw. lokal aktualisieren, dann auf den Server deployen.

Praktischer wäre es natürlich, wenn es im composer-client auch einen "Pakete installieren" button gäbe, der anhand des composer.lock Files einfach ein "composer install" ausführt, was viel weniger Speicher beansprucht. Dann könntest du lokal das composer update durchführe, die composer.lock Datei auf den Server spielen und dort dann "Pakete installieren" ausführen.

[rezico]

Okay, danke dafür schon einmal.
Was mich ehrlich gesagt tierisch interessiert: Wieso benötige ich so unheimlich viel Speicher für das updaten von ERweiterungen? Ich meine doch Composer WEIS doch jetzt um welche Erweiterungen es geht und muss doch das ganze Repo nicht mehr durchsuchen (was ja nach meinen kurzen Recherchen vor allem wegen der ganzen Symfony Erweiterungen) dann zum Abschuss führt...

Aber es geht hier sogar nur um Updates, nicht um etwas neues.

Ich schau mal wie weit ich komme, auf "alles lokal" würde ich natürlich ungern wechseln....

[Spooky]

Was mich ehrlich gesagt tierisch interessiert: Wieso benötige ich so unheimlich viel Speicher für das updaten von ERweiterungen? Ich meine doch Composer WEIS doch jetzt um welche Erweiterungen es geht und muss doch das ganze Repo nicht mehr durchsuchen (was ja nach meinen kurzen Recherchen vor allem wegen der ganzen Symfony Erweiterungen) dann zum Abschuss führt...

Erweiterungen haben Abhängigkeiten. Diese Abhängigkeiten können weitere Abhängigkeiten haben. Diese Abghängikeiten können weitere Abhängigkeiten haben, etc. Manche Abhängigkeiten können sehr komplex definiert sein. Dies muss der composer aufschlüsseln. Und diese Operation benötigt, vor allem zum derzeitigen Entiwicklungsstand, je nach Situation, viel Speicher.

[rezico]

Alles klar. Ist schon einleuchtend aber dennoch...
Habe jetzt mit Host Europe gesprochen, das Paket mit 256 MB kostet 20 Euro im Monat,.... (ich glaub aktuell zahlt der Kunde 5)

Zum PHP Prozess...

Nein bei einem Shared Hosting Produkt können Sie nicht auf die einzelnen Prozesse zugreifen. Ist allerdings auch nicht von unserer Systemadministration gewünscht. Sie liegen ja nicht alleine auf diesem Server, sondern auch viele andere Kunden.

Das ist alles mal mega kacke. Anders kann ich das nicht ausdrücken ^^

Wie hoch ist die Wahrscheinlichkeit dass das mit direktem SSH Zugriff klappt? Das Paket mit SSH kostet immerhin nur 10 Euro mtl.

Danke!

[Spooky]

Hast du den Aufruf mit

php -d memory_limit=1G -d max_execution_time=900

nun versucht oder nicht? Auf was für eine Frage bezieht sich die Antwort des Hosters? Ein Zugriff auf einzelne Prozesse ist ja nicht notwendig.

[rezico]

Ja das habe ich bereits versucht wobei

$ php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file:  Permission denied
Failed to start up concurrent users module! 

einen Fehler wird, ich musste es mit

$ /usr/bin/php php -d memory_limit=1G -d max_execution_time=900 composer.phar update --no-ansi --no-interaction --profile
Unable to create lock file: Permission denied
Failed to start up concurrent users module!
Could not open input file: php 

Daraufhin habe ich eben gefragt wo das Problem wäre und es kam:

Nein bei einem Shared Hosting Produkt können Sie nicht auf die einzelnen Prozesse zugreifen. Ist allerdings auch nicht von unserer Systemadministration gewünscht. Sie liegen ja nicht alleine auf diesem Server, sondern auch viele andere Kunden.
Sie haben nur die möglichkeit ab einem Webhosting Medium Paket die .htaccess File zu editieren, mit der Sie die PHP.ini des Servers beeinflussen können.

Man würde wohl nicht darum herum kommen auf einen VServer zu wechseln oder auf das große Webhosting Paket.

[Contao-Academy]

Ich hatte heute auch wieder mal "Out of Memory".
Das Hosting hat 256MB RAM + SSH Zugang. Hat alles nichts geholfen…
Bevor du also Experimente machst, such dir lieber ein Hosting dass wirklich 512MB oder 1GB anbietet.
Da ich keine Werbung machen will, schick mir einfach ne PN, dann nenn ich dir Hoster.

Ich muss bei dem Kunden jetzt auch die "Lokal" Variante durchziehen, da im Moment ein Umzug nicht in Frage kommt.
Alles keine schöne Lösung…

[rezico]

danke für die antwort!
ich komm darauf zurück wenn ein wechsel wirklich im bereich des möglichen steht :-)

das lokale prozedere darf man sich dann in etwa so vorstellen: man zieht sich die website lokal, macht das update und schiebt es manuell wieder hoch?

ohje.