Probleme bei update auf 6.2

Da gab es nen Bug. Den Fehler findest im Forum.

1 Like

Danke.

Ich habe nun eine neue Frage im Updateprozess:
hier
https://docs.oxid-esales.com/eshop/de/6.2/installation/update/von-6.1.x-auf-6.2.0-aktualisieren.html
bei
“Aktualisierung der Modulkonfigurationen” Unterpunkt 4 steht

“Nach diesem Arbeitsschritt sollte in der Konfigurationsdatei aller zuvor aktiven Module die Option configured = true sein. Die Konfigurationsdatei enthält jetzt auch die Moduleinstellungen. Es sind die selben, die im Administrationsbereich beim Modul festgelegt wurden.”

Wo genau finde ich diese Konfigurationsdatei?
Ich will zum einen kontrollieren ob jeder Schritt funktioniert hat und zum Anderen weiteres über den Aubauf lernen.

Danke vorab.

Sollte shopordner/var/configuration/shops/1.yaml sein. 1 für ID = 1.

1 Like

Hallo liebe OXID-Freunde,

bei der Shopupdate-Generalprobe ist leider noch ein Fehler aufgetreten … und ich hoffe, dass ihr mir einen Lösungsansatz geben könnt.

Ich bin gerade dabei, die hier beschriebenen Schritte zur Übernahme der Modulkonfiguration durchzuführen:
https://docs.oxid-esales.com/eshop/de/6.2/installation/update/von-6.1.x-auf-6.2.0-aktualisieren.html

Hier steht nun zwei mal Segmentation fault

Was bedeutet das?
Was kann ich hier tun um den Fehler zu beheben oder erst einmal zu umgehen?

Ind Backend komme ich gerade nicht rein, um dieses Modul zu deaktivieren.

Normalerweise sollte der Shop nun wieder sichtbar sein - das ist er aber noch nicht.

Danke vorab.

Steht was in den php-Logs?

Danke für die Antwort.
In der Log-Datei des Shops steht nichts zum betreffenden Zeitpunkt drinnen.

Und an die PHP-Logs komme ich nicht selber ran … gerade eben habe ich die Rückmeldung bekommen, dass dort auch nichts drinnen steht.

Segmentation Faults lassen sich ohne tiefgehende Systemanalyse nicht einzugrenzen. Das können z.B. Speicherüberläufe sein, die sich kaum auf eine einzelne Aktion festmachen lassen. Daher gibt es auch keine nutzbaren Logeinträge, da der Server meist gar nicht mehr dazu kommt, noch irgendetwas wegzuschreiben.

Allgemein wäre meine Empfehlung, den Auslöser so gut es geht zu entfernen, hier also das Modul zu entfernen, das Shopupgrade durchzuführen und das Modul wieder nach Anleitung in möglichst aktueller Version neu zu installieren.

OK, es könnte tatsächlich der Memory sein. Du kannst versuchen, COMPOSER_MEMORY_LIMIT=-1 vor den Composer-Befehl zu setzen.

Danke für Eure Anteilnahme!

Ich habe vorhin auch mit dem Support von D3 telefoniert weil der Fehler nach deren Modul aufgetreten ist - das war aber vermutlich nur ein Zufall. Und die haben weitaus mehr Erfahrung als ich.

Seine Empfehlung war auch, die großen Module vor dem Update zu deinistallieren und danach wieder zu reinstallieren.

Diese “Speichererweiterung” muste ich bereits bei composer update verwenden. Sie auch hier zu verwenden, da bin ich noch nicht drauf zu kommen (weil ich diesen Fehler ja auch gar nicht anfassen konnte) - aber das behalte ich mir mal im Hinterkopf.

Gerade mache ich ein neues Deployment für Testumgebung der Generalprobe … wenn nun alles reibungslos funktioniert, steht dem Live-Update nichts mehr im Weg.

1 Like

Mr. G00Gle gibt Memory gehäuft als Ursache an. Wenn man die php.ini nicht selbst anpassen kann, ist der Zusatz hin und wieder hilfreich.

Habe wieder den Segmentation Fault-Fehler beim Befehl:

vendor/bin/oe-console oe:module:apply-configuration

Dein Ratschlag von vorhin, COMPOSER_MEMORY_LIMIT=-1 davor zu setzen funktioniert logischerweise nur bei composer-Befehlen und nicht bei den OXID-Konsolen-Befehlen

Mein PHP Memory-Limit in der SSH-Umgebung ist

php -i | grep "memory_limit"
memory_limit => 128M => 128M

Ich versuche das mal mit dieser Anleitung hoch zu setzen:
https://www.mariusmüller.de/php-version-und-memory_limit-fuer-ssh-bei-all-inkl-einstellen/

alias php='/usr/bin/php71 -d memory_limit=512M'
php -i | grep "memory_limit"
memory_limit => 512M => 512M

(Codebeispiel spezifisch fpr All-Inkl und PHP 7.1)

und ich bekomme nun leider noch immer den Segmentation fault selbst bei 1024M
(Nachtrag: Auch mit PHP 7.2 und 7.3 und 4096M kommt dieser Fehler)

vendor/bin/oe-console oe:module:apply-configuration
Applying modules configuration for the shop with id 1:
Applying configuration for module with id bestitamazonpay4oxid
Applying configuration for module with id d3modcfg_lib
Applying configuration for module with id ddoewysiwyg
Segmentation fault

Den D3-Modul-Connector konnte ich leider nicht deinstallieren weil beim deaktivieren des Modules hatte es im Backend-Frame immer das Frontend geladen… kann ich dieses Modul mit irgendeinem Konsolen-Befehl sauber deaktiviern und deinstallieren?

vendor/bin/oe-console oe:module:deactivate d3modcfg_lib
It was not possible to deactivate module - "d3modcfg_lib", maybe it was not active?

Hat leider auch nicht funktioniert… bin ich nun dafür einen Schritt zu weit? Muss ich eventuell wieder ein neues Deployment vornehmen?

Das Einzige, das mir dazu momentan einfällt: Welche php-Version benutzt der Composer?

Der Shop läuft unter PHP 7.1
Der Composer unter SSH läuft mit PHP 7.2 (wenn ich 7.1 einstelle, dann bringt mir composer update bei irgendeinem der vielen Module einen Fehler).

Bezüglich dem Segmentation fault habe ich aber vorhin schon PHP 7.1, 7.2 und 7.3 durchprobiert.

Kann ich im jetzigen Zusand des Shops irgendwie über die Console Module deinstallieren oder muss ich hier wieder einige Schritte zurück?

[quote=“Sir_Paladin, post:21, topic:98061”]
wenn ich 7.1 einstelle, dann bringt mir composer update bei irgendeinem der vielen Module einen Fehler)
[/quote]`

–ignore-platform-reqs

Versucht?

Das kannte ich noch nicht … wieder was gelernt … ich probiere es morgen nochmal.

Das Live-Shopupdate ist nun endlich durch … aber es war rückblickend eine schwere Geburt.

Wie von Daniel empfohlen hatte ich alle D3-Module deinstalliert.
Bei der Deaktivierung des Modulconnectors über das backend trat ein Fehler auf, weshalb ich das Modul nicht deaktivieren konnte. … extrem seltsamer Fehler (denn dieser Fehler ist bem Support von D3 nicht aufgetreten). Nachdem ich meine Cookies zum Shop gelöscht hatte, konnte ich auch endlich dieses Mudul deaktivieren. … sehr komisch!

Dann habe ich wieder meine Update-Generalprobe begonnen…
und dabei kam WIEDER dieses Segmentation error.

In meiner Verzweiflung hatte ich dann diesen Befehl mehrmals hintereinander (Pfeil hoch → Enter) (mit oben beschriebener Speicherplatzerhöhung für PHP) ausgeführt und beim dritten mal lief das Skript durch. Juhuuu! Aber dennoch mit einem negativem Beigeschmack. Naja.

Als ich dann das Live-Update durchgeführt hatte, kam wieder der Segmentation error.
Und beim zweiten mal nicht mehr, dafür aber ein PHP-Fehler, der das Skript abbrach.
Selber PHP-Fehler hatte ab da dann auch das composer update blockiert.

Es war ein Fehler im paypalplus-Modul im Zusammenhang mit onDeavtivate.
Modul über die Konsole deaktivieren hatte den selber Fehler geworfen.
→ Dann hatte ich das onDeactivate-Event aus der yaml-Datei chirurgisch entfernt.
→ Ab da haben dann wieder alle Schritte funktioniert.

Zu meiner Überrsachung: Die installation und Konfiguration des neuen PayPal-Checkout-Moduls funktioniert komplett reibungslos.

Danke nochmal für Eure Anteilnahme.

Nachtrag: Das Modul für die Trusted-Shops-Integration ist auch auf ominöse Art und weise verschwunden … aber das ist kein Beinburch. Es schein inkompatibel gewesen zu sein - irgendein Skript hatte hier eine rote Meldung gebracht mit dem Hinweis, dass die MAtadata-Version 1.1 nicht mehr unterstützt wird.

Ich muss leider nochmal eine Frage in den Raum stellen.
Irgendwie habe ich mir irgendwas kaupttgemacht und nun habe ich Verständnisprobleme.

Wenn ich
COMPOSER_MEMORY_LIMIT=-1 composer update --no-dev
ausführe, dann geht der Shop kaputt. Weiße Seite im Frontend und Backend.
Vermutlich wird der autoloader gar nicht generiert. Siehe:


Warum werden diese Komponenten deinstalliert?

Wenn ich
COMPOSER_MEMORY_LIMIT=-1 composer install
ausführe, werden diese Komponenten wieder re-installiert und der Shop läuft wieder.
Siehe:

Das hier ist ein Auszug aus der composer.json:

Was habe ich hier verkehrt gemacht?
Warum verhält der sich so?

Danke vorab.

Du hast in deinem Shop die Pakete unter “require-dev” bereits installiert. Wenn du jetzt composer update mit dem Parameter “–no-dev” aufrufst, dann werden diese wieder deinstalliert, und das verursacht manchmal Probleme. Wenn du composer install aufrufst, werden die Versionen aus der composer.lock installiert, also quasi der letzte Zustand, und da sind die Pakete wieder dabei. Ich würde den --no-dev Parameter in Zukunft bei composer update einfach erstmal weglassen.

Dann kannst du schauen welche PHP-Version in deinem Frontend aktiv ist (kann man im Backend sehen unter Systeminfo), und welche PHP-Version auf der Kommandozeile aktiv ist (“php -v”). Wenn die Version in der Kommandozeile abweicht, kannst in der composer.json die Version, für die kompiliert wird, explizit setzen: Enforcing a PHP Version for Installed Composer Packages – Andy Carter
Das sollte dann die Version sein die im Frontend verwendet wird.

1 Like

Vielen Dank für die ausführliche Erklärung der Hintergründe.
Wenn ich das --no-dev weglasse funktioniert bei mir.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.