Beim Update von 5.3.2 auf 5.3.3 bekomme ich zunächst die Meldung „Update wurde gestartet“, dann läuft der Fortschrittsbalken fürs Entpacken durch und dann bekomme ich die Meldung:
„The server could not handle the request. Please choose a smaller batch size.“
Im Verzeichnis files/update sind danach auch einige neue Ordner und Dateien.
Ich habe den Shop lokal entwickelt und es ist glaube ich das erste Update, dass ich auf dem Server starte. Kann sein, dass es ein grundsätzliches Problem ist.
Ich habe hier im Forum einige Beiträge und Lösungsansätze gefunden (php zip extension fehlt, fehlerhafte Dateien im update Ordner, upload_max_filesize). Aber das entzippen scheint zu funktionieren, den Ordner files habe ich mal komplett gelöscht, die Skriptlaufzeit steht auf 120 Sekunden und die filesize bei 50 MB. Trotzdem funktioniert es nicht.
Hat jemand eine Idee was das sein könnte bzw. wie man das Einkreisen kann?
Danke
Andreas
Hey,
das unzip Script scheint nicht in der Lage sein die ZIP Datei zu entpacken - dies kann unterschiedlichste Gründe haben. Eine Lösung dafür wird nur dein Hoster haben, wir bieten jedoch auch den klassischen Updateweg über den Browser an. Lade dir dafür einfach das Update-Package auf unserer Downloadseite herunter und entpacke dies selbst über den Server. Im Anschluss sollte beim Neuladen des Shops automatisch die Weiterleitung zum Updateprozess kommen. Wenn nicht, ruf die Seite auf, in dem du an den Host „/recovery/update“ hängst.
Ich hoffe dir hilft das weiter!
LG Andre
Sorry wenn ich auf dem Schlauch stehe - aber wohin entpacken. In files/updates/files?
Oder soll ich mit den Dateien aus dem zip die Dateien auf dem Server überschreiben?
Bist Du Dir sicher, dass es am Entpacken liegt. Wie schon geschrieben habe ich ja nach dem Versuch das Update zu starten auch Ordner und Dateien im update Ordner liegen. Allerdings könnte das vorzeitig abbrechen?
Danke
Andreas
Gibt es denn Fehlermeldungen im Error-Log der Website oder in den Shopware-Logs?
Timme Hosting - schnelles nginx-Hosting
www.timmehosting.de
Sorry für die lange Pause,
ich habe zunächst mal das Backup wieder eingespielt und das Update hinten angestellt, weil ich nicht mehr die Zeit dafür hatte. Das Problem ist aber nocht nicht behoben. Ich habe mir jetzt erst mal wieder eine aktuelle Version vom Server gezogen und auf meinem lokalen Entwicklungsserver installiert. Jetzt kann ich auch auschließen, dass es am php zip liegt. Der Fehler tritt aber auch lokal auf.
Im Shopware Log steht:
[2017-12-05 17:15:00] core.ERROR: Symfony\Component\Filesystem\Exception\IOException: Cannot rename "/usr/www/users/XXXXX/files/update/files/recovery/common/vendor/composer/autoload_psr4.php" to "/usr/www/users/XXXXX//recovery/common/vendor/composer/autoload_psr4.php". in /usr/www/users/XXXXX/vendor/symfony/filesystem/Filesystem.php:289 Stack trace: #0 /usr/www/users/XXXXX/engine/Shopware/Plugins/Default/Backend/SwagUpdate/Controllers/Backend/SwagUpdate.php(421): Symfony\Component\Filesystem\Filesystem->rename('/usr/www/users/...', '/usr/www/users/...', true) #1 /usr/www/users/XXXXX/engine/Shopware/Plugins/Default/Backend/SwagUpdate/Controllers/Backend/SwagUpdate.php(366): Shopware_Controllers_Backend_SwagUpdate->replaceRecoveryFiles('/usr/www/users/...') #2 /usr/www/users/XXXXX/engine/Library/Enlight/Controller/Action.php(159): Shopware_Controllers_Backend_SwagUpdate->unpackAction() #3 /usr/www/users/XXXXX/engine/Library/Enlight/Controller/Dispatcher/Default.php(530): Enlight_Controller_Action->dispatch('unpackAction') #4 /usr/www/users/XXXXX/engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) #5 /usr/www/users/XXXXX/engine/Shopware/Kernel.php(184): Enlight_Controller_Front->dispatch() #6 /usr/www/users/XXXXX/vendor/symfony/http-kernel/HttpCache/HttpCache.php(491): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #7 /usr/www/users/XXXXX/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL) #8 /usr/www/users/XXXXX/vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true) #9 /usr/www/users/XXXXX/engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true) #10 /usr/www/users/XXXXX/shopware.php(118): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request)) #11 {main} [] {"uid":"e9cd0a8"}
Sieht für mich nach Problem mit Rechten aus. Da das Update aber via php zip entpackt wird, haben die Dateien ja die Rechte des apache. Dann müssten die Rechte doch automatisch stimmen? Server Logs sind jetzt nicht so meine Welt ich habe mal gesucht und was gefunden in /var/log/apache2/error.log - schien mir aber nichts relevantes / zur Zeit passendes zu stehen.
Bin für jede Hilfe dankbar, ich bekomme das einfach nicht aktualisiert.
Danke
@analog.eins schrieb:
Sieht für mich nach Problem mit Rechten aus. Da das Update aber via php zip entpackt wird, haben die Dateien ja die Rechte des apache. Dann müssten die Rechte doch automatisch stimmen?
Nicht unbedingt, das hängt davon ab, in welchem Modus Du PHP betreibst. Wenn Du mod_php einsetzt, dann sollten die Rechte des Apache reichen. Wenn Du PHP aber z.B. als FPM oder FastCGI einsetzt, dann laufen die PHP-Prozesse unter einem eigenen Benutzer/einer eigenen Gruppe, so daß die PHP-Dateien dann auch diesem Benutzer/dieser Gruppe gehören sollten bzw. der Benutzer/die Gruppe Lese- und ggf. Schreibrechte auf die Dateien haben sollten.
Timme Hosting - schnelles nginx-Hosting
www.timmehosting.de
Da komme ich an meine Grenzen - keine Ahnung in welchem Modus ich PHP betreibe. Ich sage mal: default Konfiguration unter ubuntu.
Ich bin mir allerdings auch gar nicht sicher, was die Einträge im Shopware Log bedeuten. Ich habe zwischenzeitlich testweise der Gruppe und dem Besitzer Schreib- und Leserechte auf das ganze Shopwareverzeichnis gegeben. Das hilft mir aber auch nicht weiter.
Kann mir jemand sagen, was die Einträge im Log bedeuten?
Hallo allerseits,
ich habe jetzt eine Kopie des Shops noch auf einem dritten Server getestet (ander Shopware Installationen die dort liegen lassen sich problemlos installieren). Auch dort selbe Fehlermeldung und gleicher Eintrag im Log. Dort habe ich auch mal ein chmod 777 gemacht - es scheint auch nicht an mangelnden Rechten zu liegen.
Aktueller Stand
- Ich habe einen Produktivshop, den ich nicht mehr aktualisieren kann und ich werde langsam ernsthaft nervös
- Es scheint nicht am php zip zu liegen
- Es scheint nicht an korrupten Dateien im /files Ordner zu liegen
- Es ist wahrscheinlich keine Rechteproblem
- Ich kann ziemlich sicher ausschließen, dass des am Server / der Konfiguration liegt
- Ich verstehe den Eintrag im Shopware Log nicht
Das wichtigste wäre mir zunächst überhaupt erst mal diesen Eintrag im Log zu verstehen
[2017-12-08 07:23:52] core.ERROR: Symfony\Component\Filesystem\Exception\IOException: Cannot rename "XXXXX/files/update/files/recovery/common/vendor/composer/autoload_files.php" to "XXXXX//recovery/common/vendor/composer/autoload_files.php". in XXXXX/vendor/symfony/filesystem/Filesystem.php:289 Stack trace: #0 XXXXX/engine/Shopware/Plugins/Default/Backend/SwagUpdate/Controllers/Backend/SwagUpdate.php(421): Symfony\Component\Filesystem\Filesystem->rename('/kunden/356014_...', '/kunden/356014_...', true) #1 XXXXX/engine/Shopware/Plugins/Default/Backend/SwagUpdate/Controllers/Backend/SwagUpdate.php(366): Shopware_Controllers_Backend_SwagUpdate->replaceRecoveryFiles('/kunden/356014_...') #2 XXXXX/engine/Library/Enlight/Controller/Action.php(159): Shopware_Controllers_Backend_SwagUpdate->unpackAction() #3 XXXXX/engine/Library/Enlight/Controller/Dispatcher/Default.php(530): Enlight_Controller_Action->dispatch('unpackAction') #4 XXXXX/engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp)) #5 XXXXX/engine/Shopware/Kernel.php(184): Enlight_Controller_Front->dispatch() #6 XXXXX/vendor/symfony/http-kernel/HttpCache/HttpCache.php(491): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #7 XXXXX/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL) #8 XXXXX/vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true) #9 XXXXX/engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true) #10 XXXXX/shopware.php(118): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request)) #11 {main} [] {"uid":"775e43b"}