Hallo Leute,
verwendete Version 5.6.7.
Wollte endlich Updaten auf die neue 5.7.2.
Backup gemacht.
Starte das Update aus dem Programm heraus es nudelt für die Unendlichkeit.
Also übers Backend versucht.
Die neuste Version runtergeladen, dann wieder hochgeladen enzippt und das Update gestartet.
Läuft wieder bis Cleanup ettliche Daten werden angezeigt und dann nudelt das solange bis eine 500, bzw. 503 Seite erscheint.
Also das ganze noch mal, diesmal mit der nächstfolgenden Version die ich derzeit auf dem Server habe.
Das gleiche Spiel.
X-Versuche, die am Ende dazu geführt haben, das meine Shops nicht mehr angezeigt wurden, weil eine Datei, bzw. mehrere beim Cleanup gelöscht wurden.
Hat mich dann Stunden gekostet eines meiner komplett Backups zu entzippen und diese gelöschten Daten wieder zu ersetzen.
Im Moment sind die Shops zugänglich, funktionieren also.
Aber irgendwas muss da im Argen sein, wenn es bei dem Update so Probleme gibt.
Was also tun?
Im Netz habe ich dazu nichts gefunden was mir wirklich weitergeholfen hat.
Ich bin wie immer um jede Hilfe dankbar.
Gruß Joachim
Hallo Joachim,
bitte prüfe vor einem erneuten Update unter ? > Softwareaktualisierung, ob für alle Plugins ein Update zur Verfügung steht. Bei einigen Plugins können Probleme auch durch die PHP Version auftreten, als Beispiel ist das Plugin mit 5.7.2 kompatible aber nicht mit PHP 7.4.X.
In vielen Fällen tritt der Effekt mit dem Aufräumen nicht auf, wenn Du direkt vor dem Update den Cache leerst.
Ich hatte alle von mir installierten PlugIns deaktiviert, ohne irgendwelche Veränderungen.
Der Ablauf lief immer gleich ab wie schon eim ersten Threat geschildert.
Gruß Joachim
Habe schon länger das selbe Problem. Auch bei mir sollten sollten alle Plugins kompatibel sein. Irgendwas stimmt mit dem Update einfach nicht, weil sich die Fälle häufen. Ich hoffe es erledigt sich mit einem nächsten Update von selbst.
Danke für Deinen Tip, da wäre ich selber gar nicht draufgekommen.
Das sind diese Sinnlosen Antworten, die mich schon immer begeistert haben.
Lesen hilft manchmal. Besser noch verstehen was da geschrieben steht.
Gruß Joachim
500er Fehler stehen für Serverprobleme. Ein Blick in die Serverlogs sollte dir also Abhilfe schaffen, bzw. zeigen wo genau der Fehler liegt.
Also, entweder selbst auslesen oder den Hoster fragen. Die Fehlermeldungen kannst du dann gerne posten und Leute können helfen.
Grundsätzliche gebe ich Dir da recht.
Im Moment scheue ich mich davor ein Update erneut zu versuchen, weil das mit dem Risiko verbunden ist, das ich wieder stundenlang nicht erreichbar bin.
Ich kann wenn ich ein Update anstoßen würde, nur das nehmen was als nächstes Version zu meiner jetzigen Version kommt.
Das aktuellste funktioniert ja bei mir nicht, das nudelt ja nur.
Ich habe mal aus der Error Log das von dem besagten Tag rauskopiert.
Wie kann ich denn das hier einstellen? Ist ziemlich lang, jedenfalls länger als man Text hier reinkopieren kann.
Den Server betreibe ich selber.
Um in einer LOG was erkennen zu können, müsste man wissen, wonach man suchen muss.
Ohnen das Wissen, würde ich da reinschauen wie ein Schwein ins Uhrwerk. Das übersteigt meinen Horizont.
Bei einem Update kann ich aus eigener Erfahrung nur empfehlen es vorher mal in einer Staging Umgebung durchzuspielen bevor man das Update an einem produktiven Shopsystem vornimmt.
Ich habe letztens bei uns in einer Staging Umgebung das Update von 5.6.9 auf 5.7.2 durch gespielt.
Das Update selbst ist ohne Probleme durchgelaufen. Ich musste im Nachgang aber zwei Plugins (über die Datenbank) deaktivieren damit Frontend und Backend wieder erreichbar sind.
Ansonsten wäre die Fehlermeldung interessant um das Problem in diesem Fall weiter eingrenzen zu können.
Der Fehler müsste dann entweder im Apache Error-Log oder im Shopware Core Log enthalten sein.
Apache Error Log befindet sich auf dem Server z.B. unter /var/log/apache2/error.log
Den Shopware Error Log findest du auch im Backend unter Einstellungen → Logfile → Tab: System-Log und dann die Datei core_production_<year>-<month>-<day>.log
Die Fehlermeldung selbst kannst du hier als Text einfach rein kopieren. Normal sollte die ja nicht soooo lang sein als dass sie hier nicht reinpassen sollte, oder?
Ggf. einfach den Text abschneiden, evtl. erkennt man ja etwas aus den ersten paar Zeilen heraus.
Interessant ist ja nur die entsprechende Fehlermeldung und nicht der gesamte Log.
Dafür einfach mal gucken welche Log Einträge eine passende Uhrzeit haben (als der Fehler aufgetreten ist).
Ich hatte aber bei einem meiner Versuche auch mal eine vorherige PHP genommen, weil ich ja auch versucht hatte die nächst folgende Shopware Version zu installieren und ich hatte es auch mal mit der nächst höheren PHP Version probiert.
Gruß Joachim
Die PHP Version müsste OK sein.
Bis auf 7.4.14 sollten alle 7.4.X Versionen mit SW kompatibel sein.
Nach einem Plugin sieht der Fehler jetzt erstmal auch nicht aus.
Es ist aber extrem komisch dass da teilweise die Shopware Funktionen z.B. 5 Parameter im Funktionsaufruf erwarten aber nur 4 Parameter erhalten.
Klingt fast ein wenig, als würden die Dateien nicht mehr zueinander passen.
Evtl. nicht alles vom Update auf dem Server eingespielt worden?
Ggf. zum Teil fehlende Schreibberechtigungen beim unzippen gehabt oder ähnliches?
Der folgenden Fehler deuten auf eine Fehlkonfiguration vom FPM hin vermute ich mal.
[Sun Aug 29 14:24:02.557567 2021] [proxy:error] [pid 16648] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /var/www/vhosts/system/xxxxxxxxxxxxxxxx.de/php-fpm.sock (*) failed
[Sun Aug 29 14:24:02.557603 2021] [proxy_fcgi:error] [pid 16648] [client XX.XX.XXX.XX:XXXXX] AH01079: failed to make connection to backend: httpd-UDS
Hatte letztens in einer lokalen Testumgebung den gleichen Fehler.
Ursache war, weil ich auf FPM umgestellt habe, aber im vHost http2 / ssl connection nicht abgefangen habe sondern nur die Port 80 Konfiguration im vHost hinterlegt hatte.
Na ja, die Updates davor haben ja auch immer geklappt.
Ich fummele da auch nicht gleich tiefgreifend drin rum, wenn was nicht gleich auf anhieb funktioniert.
Es kann natürlich sein, das es bereits beim ersten Versuch die 5.7.2 einzuspielen, als sich das Teil todnudelte schon zu löschaktionen gekommen ist.
Alle anderen Versuchen haben dann ggf. den Rest noch durcheinander gebracht.
Ich hatte tatsächlich auch mal auf FastCGI umgestellt gehabt, aber da ging überhaupt nichts, also alles wieder zurückgestellt. Wahrscheinlich habe ich gerade diesen Teil hier reinkopiert
Fragt sich was man da noch machen kann?
An dieser Stelle bringe ich noch einen anderen Aspekt vor, der mir im Vorfeld aufgefallen ist, direkt mit den Update aber nichts zu tun hat. Vielleich deutet das aber schon auf ein länger schwelende Problem hin.
Wann immer ich Artikelupdates einbringe, leere ich auch den Shop Cache und die anderen Caches.
Hier ist mir dann aufgefallen das irgendwann mal angefangen hat, das das Fenster „Cache Verzeichnis Information“ ewig genudelt hat und am Ende nichts angezeigt hat.
Das musste und muss man noch immer zig mal wiederholen bis das enlich angezeigt wurde/wird und erst dann konnte man die Cache + das Template Kompilieren starten.
Ob das ein Hinweis ist weiß ich nicht, aber das sollte ich nicht unerwähnt lassen.
Gruß Joachim
Hier noch mal ein späterer Zeitpunkt:
[Sun Aug 29 18:26:56.497549 2021] [proxy_fcgi:error] [pid 27917] (70007)The timeout specified has expired: [client 89.246.121.10:22474] AH01075: Error dispatching request to : (polling), referer: https://xxxxxxxxxxxxxxxx/recovery/update/cleanup?
[Sun Aug 29 18:35:53.120509 2021] [proxy_fcgi:error] [pid 27909] [client 216.244.66.234:35340] AH01071: Got error ‚PHP message: PHP Fatal error: Uncaught Doctrine\ORM\Mapping\MappingException: The target-entity Shopware\Models\Attribute\Emotion cannot be found in ‚Shopware\Models\Emotion\Emotion#attribute‘. in /var/www/vhosts/xxxxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:772\nStack trace:\n#0 /var/www/vhosts/xxxxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php(1032): Doctrine\ORM\Mapping\MappingException::invalidTargetEntityClass()\n#1 /var/www/vhosts/xxxxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(266): Doctrine\ORM\Mapping\ClassMetadataInfo->validateAssociations()\n#2 /var/www/vhosts/xxxxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php(245): Doctrine\ORM\Mapping\ClassMetadataFactory->validateRuntimeMetadata()\n#3 /var/www/vhosts/xxxxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/doctrine/persistence/lib/Doc…‘
Ich habe es jetzt mit der 5.7.3 versucht über den Shop nudelt es nur, ansonsten passiert nichts.
Jetzt habe ich es über den Server versucht. Das läuft wieder bis Cleanup und endet mit einer 503 Seite.
Ich habe dann die URL mehrmals gestartrt und dann kommt diese Fehler meldung.
Unabhängig davon, muss in meiner Servereinstellung irgendwas falsch eingestellt sein. Da das bisher immer Problemlos funktioniert hat, könnte es an irgendeinen Serversoftware seitigen Update liegen.
Hätte da jemand eine Ide, wonach man schauen könnte?
Gruß Joachim
Slim Application Error
The application could not run because of the following error:
Details
Type: ErrorException
Code: 2
Message: require(/var/www/vhosts/xxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/composer/…/…/engine/Shopware/Application.php): failed to open stream: No such file or directory
File: /var/www/vhosts/xxxxxxxxxxxxxx.de/httpdocs/xxxxx/vendor/composer/autoload_real.php
Line: 73
Habe gerade nachgeschaut. Die Datei ist aber genau da wo Sie sein soll. Jedenfalls ab httpdocs.
Stellt sich mir die Frage, wenn man davon ausgeht der vordere Teil des Pfandes wäre falsch, wie das passieren kann. Ich mache da überhaupt nichts.
Die zweite Frage, die sich daraus ergibt, wäre, wie ich das ändern könnte.
Gruß Joachim