Einzelne Module per Konsole aktualisieren?

[Kahmoon]

Tach beisammen.....

Ich bekomme schon wieder Speicherfehler bei Composer und 1und1....dabei bin ich erst kürzlich auf das Unlimited Pro! Paket gewechselt (512 MB)..... Pakete aktualisieren ist nicht mehr möglich. *Hass*. Braucht man für einen Composer jetzt vielleicht einen eigenen Root Server mit 64 GB RAM?

Ich kann doch über Konsole auch einzelne Pakete aktualisieren oder?

php5.5 composer.phar update contao-legacy/dlh_googlemaps

Aber auch da bekomme ich eine Speicherfehler.....was kann ich tun? :-)

VG
Franky

[Thraile]

Wenig - auch wenn du nur ein Paket aktualisierst müssen ja alle Abhängigkeiten überprüft werden.

Du könntest mal die Option prefer stable zu aktivieren, dann müssen weniger Optionen geprüft werden.

Alternativ Hoster wechseln 😀 - bei DF hat man z.B. bei cli Aufrufen deutlich mehr Speicher für Verfügung.

Gesendet von meinem D5803 mit Tapatalk

[Spooky]

Nur nebenbei, warum verwendest du dlh_googlemaps über contao-legacy?

[Kahmoon]

Weil ich kein anderes gefunden habe? Hat mich auch gewundert. Ändert aber auch nichts . Es geht ja nichts mehr im Composer-....

1und1 meinte auch dass das Paket die höchstmögliche Speichereinstellung von 512 MB hat und das Problem vermutlich woanders liegt. Kann doch nicht sein das der so viel braucht!?

[Spooky]

Weil ich kein anderes gefunden habe? Hat mich auch gewundert. Ändert aber auch nichts . Es geht ja nichts mehr im Composer-....

Eigentlich sollte dir das der composer-client direkt anzeigen. Das Original Paket ist delahaye/dlh_googlemaps.

Kann doch nicht sein das der so viel braucht!?

Doch, der Speicherverbrauch beim auflösen der Abhängigkeiten kann sogar über 1 GiB (oder mehr) steigen.

1und1 meinte auch dass das Paket die höchstmögliche Speichereinstellung von 512 MB hat und das Problem vermutlich woanders liegt.

Das Problem ist, dass zuwenig Speicher vorhanden ist, 512 MiB reicht für deine Composer Operation nicht aus. Und soweit ich deine Posts richtig verstehe, hast du zwar SSH Zugriff, aber 1&1 hat den Webserver so eingestellt, dass selbst im CLI Environment von PHP nur 512 MiB zur Verfügung stehen? Ist das tatsächlich so?

[Kahmoon]

Ja, das delaheye Paket hatte ich eigentlich. Nur mit suche "maps" kommt das leider nicht...wenn man genau nach dem Namen sucht schon.


Ich weiss nicht genau obs beim SSH Zugang anders ist..es kommt aber die gleiche Fehlermeldung. Aber ich habe zu wenig Ahnung von Konsole um das sicher sagen können. Ich hab nur den SSh Zugang im Backend angelegt....Optionen gibt es da nicht. Und die Hotline sagte auch das es keine Pakete mit mehr Speicher gibt...außer eigener Server natürlich.

Fehlermeldung

Fatal error: Out of memory (allocated 686292992) (tried to allocate 32 bytes) in phar:///homepages/46/d346729057/htdocs/xxx/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60"

[Contao-Academy]

Das gleiche Problem hatte ich vor kurzem bei einem anderen Hoster auch. Als Workaround blieb leider nichts anderes übrig, wie die Installation lokal zu ziehen, dann ein Update der Pakete zu machen und wieder auf den Server zu schieben. Das Thema Composer und Speicher ist im Moment sehr, sehr nervig :-(

[Spooky]

Nur mit suche "maps" kommt das leider nicht...wenn man genau nach dem Namen sucht schon.

Die Suche im composer-client ist sehr rudimentär und nicht vollständig ausimplementiert. Darüberhinaus ist du Suche auf packagist.org auch eher einfach gehalten. Besser ist es, man sucht sich den genauen Paketnamen über andere Wege.

Ich weiss nicht genau obs beim SSH Zugang anders ist..es kommt aber die gleiche Fehlermeldung. Aber ich habe zu wenig Ahnung von Konsole um das sicher sagen können.

Welchen Befehl genau verwendest du nun?

Und die Hotline sagte auch das es keine Pakete mit mehr Speicher gibt...außer eigener Server natürlich.

Die Hotline hat dich wahrscheinlich falsch verstanden. Dir geht es ja um das Memory Limit über das Command Line Interface. Und dort steht sehr wohl mehr Speicher zur Verfügung, wie man anhand deiner Fehlermeldung sieht:

Fatal error: Out of memory (allocated 686292992) (tried to allocate 32 bytes) in phar:///homepages/46/d346729057/htdocs/xxx/composer/composer.phar/src/Composer/DependencyResolver/Rule.php on line 60"

Das sind 654.5 MiB. Aber das ist halt auch immer noch zu wenig.

[Kahmoon]

Das ist dr Befehl + Warnhinweis

(uiserver):u60854035:~/xx/composer$ php5.5 composer.phar update
X-Powered-By: PHP/5.5.38
Content-type: text/html

Warning: Composer should be invoked via the CLI version of PHP, not the cgi-fcgi SAPI
Loading composer repositories with package information
Updating dependencies (including require-dev)

1und1 kann es sich nicht erklären.... ich brauche viel mehr Speicher als alle anderen Kunden und habe auch schon mehr als ich haben dürfte. Irgendwas is da im Composer faul vermute ich.


Frage ist jetzt: Was kann ich tun.....kann ich Composer einfach mal neu installieren? Das ist halt eine Installation auf der drei Domains laufen.

Anbei noch meine Composer Config

{
    "name": "local/website",
    "description": "A local website project",
    "type": "project",
    "license": "proprietary",
    "require": {
        "bugbuster/botdetection": ">=3.4.0.0,<3.5-dev",
        "bugbuster/contao_grid_16_columns": ">=3.2.5.0,<3.3-dev",
        "bugbuster/dlstats": ">=3.9.2.1,<3.10-dev",
        "cgo-it/xls_export": ">=3.0.0.0,<3.1-dev",
        "christianbarkowsky/contao-urlcleaner": ">=1.1.0.0,<1.2-dev",
        "codefog/contao-cookiebar": ">=1.1.1.0,<1.2-dev",
        "contao-community-alliance/composer-client": ">=0.16.4.0,<0.17-dev",
        "contao-legacy/ajax": "~1.1",
        "contao-legacy/backupdb": ">=3.2.2.9004,<3.3-dev",
        "contao-legacy/calendar_extended": ">=3.6.0.9032,<3.7-dev",
        "contao-legacy/cameraslideshow": "1.1.2.9005",
        "contao-legacy/efg": "2.2.1.9005",
        "contao-legacy/pageimage": ">=3.1.3.9007,<3.2-dev",
        "contao-legacy/simple_event_registration": "3.2.0.9006",
        "contao-legacy/tags": ">=3.4.2.9010,<3.5-dev",
        "delahaye/dlh_googlemaps": ">=2.2.0.0,<2.3-dev",
        "dklemmt/contao_dk_mmenu": ">=1.5.1.0,<1.6-dev",
        "heimrichhannot/contao-ce_page_teaser": ">=1.5.4.0,<1.6-dev",
        "jrgregory/m17-sticky-backend-footer": ">=2.0.4.0,<2.1-dev",
        "lionel/superfish": ">=3.2.0.0,<3.3-dev",
        "madeyourday/contao-rocksolid-antispam": ">=1.0.4.0,<1.1-dev",
        "menatwork/contao-multicolumnwizard": ">=3.3.3.0,<3.4-dev",
        "psi/glossary": ">=1.4.3.0,<1.5-dev",
        "richardhj/contao-childlayouts": ">=1.1.3.0,<1.2-dev",
        "terminal42/contao-ce-access": ">=2.0.3.0,<2.1-dev",
        "terminal42/contao-easy_themes": ">=2.2.2.0,<2.3-dev",
        "terminal42/contao-pageimage": ">=3.2.0.0,<3.3-dev",
        "terminal42/contao-tablelookupwizard": ">=2.0.1.0,<2.1-dev"
    },
    "prefer-stable": true,
    "minimum-stability": "dev",
    "config": {
        "preferred-install": "dist",
        "cache-dir": "cache",
        "component-dir": "../assets/components"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://legacy-packages-via.contao-community-alliance.org/"
        },
        {
            "type": "artifact",
            "url": "packages"
        }
    ],
    "extra": {
        "contao": {
            "migrated": "done",
            "version-locks": {
                "contao-legacy/urlcleaner": ">=1.1.0.3005-beta,<1.2-dev@beta",
                "contao-legacy/efg": ">=2.2.1.9005,<2.3-dev",
                "contao-legacy/tags": ">=3.3.1.9004,<3.4-dev",
                "contao-legacy/calendar_extended": ">=3.2.0.9114,<3.3-dev",
                "contao-legacy/simple_event_registration": ">=3.2.0.9006,<3.3-dev",
                "contao-legacy/cameraslideshow": ">=1.1.2.9005,<1.2-dev",
                "contao-legacy/pageimage": ">=3.1.2.9005,<3.2-dev"
            }
        }
    }
}

Nachdem ich bei der Config auf Speichern drücke kommt noch folgender Hinweis

Die Konfiguration ist gültig.
Warning: Warning: require.contao-legacy/cameraslideshow : exact version constraints (1.1.2.9005) should be avoided if the package follows semantic versioning
Warning: Warning: require.contao-legacy/efg : exact version constraints (2.2.1.9005) should be avoided if the package follows semantic versioning
Warning: Warning: require.contao-legacy/simple_event_registration : exact version constraints (3.2.0.9006) should be avoided if the package follows semantic versioning

Kann es daran liegen das ich einige Pakete gesperrt habe?

[Kahmoon]

Nachtrag...ich hab diese Domain jetzt testhalber mal auf PHP7 gestellt und siehe da...da läuft es jetzt durch. Mit 5.6 nicht.

[Spooky]

Irgendwas is da im Composer faul vermute ich.

Jein. Das Auflösen der Abhängigkeiten verbraucht einfach viel Speicher. Das ist so. Das wird sich in einer zukünftigen Version von Composer evt. mal ändern, aber momentan ist das einfach so. Und ich glaube 1&1 bzw. du verstehst das Problem immer noch falsch. "Du", also deine Web Applikation braucht nicht so viel Speicher. 1&1 geht wahrscheinlich davon aus, dass du davon sprichst, dass deine Web Applikation so viel Speicher braucht. Das ist aber nicht so. Contao selbst verbraucht nur einen Bruchteil davon, was Composer während dem auflösen der Abhängigkeiten braucht. Das ist aber etwas völlig anderes und vom regulären Betrieb der Website komplett losgelöst. Du musst das Problem 1&1 genauer erklären. Nämlich dass du eine Operation über die Konsole machen möchtest, im genauen ein composer update, und diese Operation viel Speicher benötigt, du aber selbst über die Konsole nicht genug Speicher bekommst. Es kann natürlich sein, dass die Leute bei 1&1 nichts von Composer, Symfony oder sonstigen, üblichen Web Development Dingen Ahnung haben.

kann ich Composer einfach mal neu installieren?

Das bringt nichts.

Kann es daran liegen das ich einige Pakete gesperrt habe?

Ich glaube nicht, dass das eine große Auswirkung auf das Dependency Resolving hat.

[Kahmoon]

Moin,

ich hab ihnen gesagt das der Speicher nicht von Contao sondern von Composer gebraucht wird. Vielleicht suggeriert das eine Webapplikation ja...hatte aber extra auch die Konsole betont. Egal ob über das Backend oder über die Konsole. Trotzdem verbraucht der Aufruf, woher auch immer, zu viel Speicher...mehr als maximal verfügbar. Was ich allerdings echt strange finde ist, das es jetzt mit PHP 7 geht...PHP 5.6 nicht.

Ich meine solang dieser Workaround funktioniert OK....aber schön ist es trotzdem nicht

Frank

[lucina]

Du musst das Problem 1&1 genauer erklären. Nämlich dass du eine Operation über die Konsole machen möchtest, im genauen ein composer update, und diese Operation viel Speicher benötigt, du aber selbst über die Konsole nicht genug Speicher bekommst.

Inzwischen sollten die das schon einige male gehört haben - was aber nichts daran ändert, dass 1und1 im Regelfall für die Console nicht mehr, sondern weniger RAM zur Verfügung stellt. Sag jetzt nix.

Es kann natürlich sein, dass die Leute bei 1&1 nichts von Composer, Symfony oder sonstigen, üblichen Web Development Dingen Ahnung haben.

Am Meisten verstehen sie etwas von Marketing, Kundenbindung und Vertragsrecht.

Ich glaube nicht, dass das eine große Auswirkung auf das Dependency Resolving hat.

Es hat keine Auswirkung. Es hätte aber eine Auswirkung, die Anforderung an die Mindeststabilität mal hochzusetzen. 'Beta' oder gar 'stable'.

[Spooky]

Was ich allerdings echt strange finde ist, das es jetzt mit PHP 7 geht...PHP 5.6 nicht.

Das Memory Limit kannst du mit dem Parameter

-d memory_limit=1G

evt. selbst festlegen (kommt immer darauf an ob das unterstützt wird). Daher meine Frage nach dem genauen Command, dass du benutzt hast. Du hast diesen Parameter nämlich nicht angegeben. Bei den Default Einstellungen wäre das schon dabei (aber wie gesagt, bringt nicht immer was, kommt auf die Umgebung an).

Evt. ist bei dem CLI Interface von PHP 7 am Server eine andere Konfiguration eingerichtet, wo das memory_limit höher ist. Wobei die 654.5 MiB, die du vorher hattest, nach einem dynamischen Limit aussehen. Daher kann es sein, dass es auf die Tageszeit ankommt (bzw. auf die Gesamtauslastung des Shared Servers).

Du könntest folgendes Kommando über SSH ausführen lassen:

php -i | grep memory 

Die genaue PHP Executable musst du natürlich selbst anpassen, je nachdem (also zB php5.5 statt php, oder wie auch immer). Damit findest du raus, welches memory_limit prinzipiell eingestellt wäre.

Anbei noch meine Composer Config

{
    …
    "minimum-stability": "dev",
    …
}

Das solltest du auf "stable" setzen - denn "dev" verbraucht hier dann viel mehr Speicher für das Dependency Resolving.

// ah, hat lucina schon erwähnt.

[Kahmoon]

Sie hat mir den Tipp gegeben per php.ini das ganze hochzusetzen. Habe ich auch..auf 1024. Aber da kann man im Grunde einstellen was man will es gibt trotzdem noch ein serverseitiges Limit. In der PHP Info steht auch 1024MB.

Ich denke das es der CLI Mode bei PHP7 sein könnte.


Wegen PHP Limit über Konsole: Wie wäre denn der gesamte Befehl?

php5.5 composer.phar update -d memory_limit=1G

Es geht nur php5.5 composer.phar update. Weder php composer.phar update.... noch php7 composer.phar update... etc.

[Spooky]

Wegen PHP Limit über Konsole: Wie wäre denn der gesamte Befehl?

php5.5 composer.phar update-d memory_limit=1G

Es geht nur php5.5 composer.phar update. Weder php composer.phar update....

Das sind PHP Parameter, keine Composer Parameter, also zB:

php5.5 -d memory_limit=1G -d max_execution_time=900 composer.phar update

Bzw. in den Systemeinstellungen unter Composer-Einstellungen » PHP-Pfad/Befehl einfach nur

php5.5 -d memory_limit=1G -d max_execution_time=900

noch php7 composer.phar update... etc.

Hast du bei 1&1 nachgefragt, wie der Konsolenbefehl für PHP7 lautet?

[Kahmoon]

Danke

Nein, das mit PHP7 habe ich selbst "rausgefunden" nachdem mir 1und1 nicht weiterhelfen kann. "Sie sind ab diesem Punkt raus"

Edit:
Bei PHP7 geht das Update über das Contao Backend

[Spooky]

Naja dann probier mal php7.0

Und vergiss nicht die minimum-stability zu ändern.