Probleme bei update auf 6.2

Hallo.
Habe unsere Shop oxid-CE von Version 4.10.3 auf 6.2 upgedated. Alles prima bis bis auf Befehl views generate. Bei Ausführung "oe-eshop-db_views_generate " erhalte ich folgende Fehlermeldung :

PHP Fatal error: Uncaught Symfony\Component\DependencyInjection\Exception\ServiceCircularReferenceException: Circular reference detected for service “Psr\Log\LoggerInterface”, path: “Psr\Log\LoggerInterface → Psr\Log\LoggerInterface”. in C:\xampp7.3.1\htdocs\akbas24\vendor\symfony\dependency-injection\Container.php:297
Stack trace:
#0 C:\xampp7.3.1\htdocs\akbas24\source\overridablefunctions.php(209): Symfony\Component\DependencyInjection\Container->get(‘Psr\Log\LoggerI…’)
#1 C:\xampp7.3.1\htdocs\akbas24\vendor\oxid-esales\oxideshop-ce\source\Core\Registry.php(329): getLogger()
#2 C:\xampp7.3.1\htdocs\akbas24\vendor\oxid-esales\oxideshop-ce\source\Core\Module\ModuleChainsGenerator.php(420): OxidEsales\EshopCommunity\Core\Registry::getLogger()
#3 C:\xampp7.3.1\htdocs\akbas24\vendor\oxid-esales\oxideshop-ce\source\Core\Module\ModuleChainsGenerator.php(344): OxidEsales\EshopCommunity\Core\Module\ModuleChainsGenerator->onModuleExtensionCreationError(‘ddrdiamondsearc…’)
#4 C:\xampp7.3.1\htdocs\akbas24\vendor\oxid-esales\oxid in C:\xampp7.3.1\htdocs\akbas24\vendor\symfony\dependency-injection\Container.php on line 297
There was an error while regenerating the views. Please look at oxideshop.log for more details.

Kann mir jemand behilflich sein. Danke im Voraus

Deine Fehlermeldung deutet daraufhin, dass Schritt 4 aus der Update Anleitung 6.1 auf 6.2 nicht durchgeführt wurden ist Update from 6.1.x to 6.2.0 — OXID eShop developer documentation 6.2.0 documentation

1. Copy the file `overridablefunctions.php` from the `vendor` directory to the OXID eShop `source` directory:

cp vendor/oxid-esales/oxideshop-ce/source/overridablefunctions.php source/

Diese Datei ist bereits dort !

ich würde mir das Modul genauer angucken, in der Zeile #3 taucht ddrdiamondsearch auf.
Ich würde es einerseits deaktivieren und andererseits prüfen, ob die aktuelle Version vorhanden ist.
Die Moduldoku wurde zum letzten mal im Januar 2021 aktualisiert und da steht, dass das Modul bis OXID 6.3.1 kompatibel sei, wobei OXID 6.3.0 erst im April 2021 und 6.3.1 im August 2021 erschienen sind, es könnte also sein, dass hier ein Tippfehler ist und das Modul bestenfalls mit OXID 6.1.1 und nicht mit 6.2 kompatibel ist.

1 Like

Hallo Vanilla.
Zunächst vielen Dank für deine Antwort.
Ich komme leider nicht auf das backend um das Modul zu deaktivieren. Shop ist im Wartungsmodus.
Bevor Datenbankdump von 4.10.3 habe ich alle Module bereits deaktiviert. Meinst du mit deaktivieren was anderes ? Ich brauche dieses Modul nicht !
Ich komme leider nicht in das backend hinein um die Views updaten zu können bzw. die Module zu bearbeiten.
Oder hast du einen Tipp wie den update zum laufen bekomme ?

Ich bitte um deine Vorschläge. Bedanke mich im Voraus.

Schmeiß das Modul über den Composer raus:

composer remove vendor/modulname

Oder den Ordner des Moduls umbenennen oder löschen, beim Umbenennen vorsorglich auch die metadata.php umbenennen .

habt ihr in der config.inc.php mal blSkipViews auf true gesetzt? Dann solltet ihr auch ohne Views in den Admin kommen und die Views dort über Tools anlegen können, vielleicht hilft das

tmp leeren nicht vergessen :wink:

PS: Wir führen Updates zum Festpreis durch und können auch bei der Fehlersuche unterstützen :slight_smile:
einfach Kontakt aufnehmen über [email protected]

Hallo Oxidfreunde.

Ich versuche gerade ein Update von OXID 6.1.4 auf 6.2.0 gemäß dieser Anleitung durchzuführen:
https://docs.oxid-esales.com/eshop/de/6.2/installation/update/von-6.1.x-auf-6.2.0-aktualisieren.html

Nach Schritt 3 war der Shop komplett offline und die Logfile wird nicht befüllt - aber das nur am Rande.
Natürlich findet dies in einer Spiegelung statt.

Wenn ich nun Schritt 4 mit diesem Befehl ausführen will:

composer update --no-dev

bekomme ich in der Konsole rote SQL-Fehler, siehe Screenshot anbei

Könnt ihr mir hier helfen oder Anhaltspunkte geben?
Danke schonmal vorab!

PS: Das OXID läuft auf einem Managed Server bei All-Inkl
Hier der Link mit den Spezifikationen. Neuinstallationen von 6.3 und 6.4 haben auch funktioniert.

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?