Shopware-Update bricht wegen zu langer Laufzeit ab

Shopware 6 (German)
1

Hallo,

momentan versuche ich, einen Shop von 6.4.20.2 auf (vorerst) 6.5.8.9 zu bringen.

Momentan hängt es an der Stelle, an der bin/console system:update:finish aufgerufen wird, da die Sache wohl länger als 300 Sekunden dauert:

Get collection for identifier: "core"
migrate Migrations
  0/80 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]   0% < 1 sec/< 1 sec 103.0 MiB
  4/80 [=░░░░░░░░░░░░░░░░░░░░░░░░░░░]   5%  1 sec/20 secs 103.0 MiB
  5/80 [=░░░░░░░░░░░░░░░░░░░░░░░░░░░]   6% 2 secs/32 secs 103.0 MiB
  8/80 [==░░░░░░░░░░░░░░░░░░░░░░░░░░]  10% 3 secs/30 secs 103.0 MiB
 13/80 [====░░░░░░░░░░░░░░░░░░░░░░░░]  16% 4 secs/25 secs 103.0 MiB
 16/80 [=====░░░░░░░░░░░░░░░░░░░░░░░]  20% 5 secs/25 secs 103.0 MiB

Fatal error:  Uncaught Symfony\Component\Process\Exception\ProcessTimedOutException: The process "'/usr/bin/php8.2' '-dmemory_limit=1G' '/var/www/html/shopware/bin/console' 'system:update:finish' '--no-interaction'" exceeded the timeout of 300 seconds. in phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/process/Process.php:1156
Stack trace:
#0 phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/process/Process.php(654): Symfony\Component\Process\Process->checkTimeout()
#1 phar:///var/www/html/shopware/public/shopware-installer.phar.php/Services/StreamedCommandResponseGenerator.php(29): Symfony\Component\Process\Process->getIterator()
#2 phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/http-kernel/HttpKernel.php(101): Shopware\WebInstaller\Services\StreamedCommandResponseGenerator->Shopware\WebInstaller\Services\{closure}()
#3 phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/http-foundation/StreamedResponse.php(106): Symfony\Component\HttpKernel\HttpKernel::Symfony\Component\HttpKernel\{closure}()
#4 phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/http-foundation/Response.php(425): Symfony\Component\HttpFoundation\StreamedResponse->sendContent()
#5 phar:///var/www/html/shopware/public/shopware-installer.phar.php/index.php(33): Symfony\Component\HttpFoundation\Response->send()
#6 /var/www/html/shopware/public/shopware-installer.phar.php(56): Phar::webPhar()
#7 {main}
  thrown in phar:///var/www/html/shopware/public/shopware-installer.phar.php/vendor/symfony/process/Process.php on line 1156

Wenn ich dieses Skript (bin/console system:update:finish) später von Hand in der Konsole ausführe, läuft es irgendwann durch.

Jetzt 2 Fragen:

  1. Ist es möglich, die 300 Sekunden irgendwo hochzusetzen? In den php.ini-Files bin ich nicht fündig geworden, da sind überall nur 30 vermerkt.
  2. Ist das Update vollständig mit der „händischen“ Methode oder fehlt noch irgendetwas?

Danke und viele Grüße

js

2

Es gibt unter Umständen zahlreiche .ini für PHP. Der Wert max_execution_time einfach auf 0 setzen oder über die CLI ausführen lassen und den Wert im Command mit dran hängen.

Wenn die CLI sagt, dass alles durchgelaufen ist und du mit system:update:finish es abgeschlossen hast, dann passt alles.

3

Der timeout kommt anscheinend gar nicht aus einer .ini sondern wird in Symfony irgendwo auf 300 Sekunden gesetzt.

Laut Doku ist es nicht möglich, von 6.4.20.2 auf 6.5.x.x über composer zu updaten, sodass ich wohl bei diesem Update wirklich den ersten Teil im Browser und den letzten in der Konsole anstoßen muss.

Hier aber nun meine Frage:

Die Migrationen werden ja im Browser bereits angestoßen, allerdings wird der Command ja dann wie im Fehler zu sehen später wegen timeout vorzeitig beendet.

Ist es sicher, später das entsprechende Kommando per cli erneut aufzurufen (Idempotenz)?

Ein besserer Weg fällt mir gerade aber nicht mehr ein. Meines Erachtens sollte Shopware hier nachbessern und das Timeout hoch genug ansetzen, die Migrationen von 6.5 auf 6.6 haben bei meinem Kunden im Testlauf ca. 1 Stunde gebraucht.

Gruß

js

1 „Gefällt mir“
4

Das halte ich für sehr unwahrscheinlich, bzw. unmöglich, da die max_execution_time vor der Ausführung des Scripts definiert werden muss.

5

@Max_Shop Ich meinte tatsächlich nicht die max_execution_time für die PHP-Engine sondern einen Timeout, der in Symfony definiert ist und bei Überschreitung einen „Symfony\Component\Process\Exception\ProcessTimedOutException“ schmeißt und deshalb auf Code-Level implementiert sein muss (siehe Fehlermeldung oben sowie The Process Component (Symfony 5.x Docs)).

Deshalb halte ich Shopware für verantwortlich, diesen Timeout bei Ausführung des Kommandos hoch genug zu setzen.

Wir haben hier anscheinend keine Chance diesen Timeout mit vertretbarem Aufwand zu verändern.

1 „Gefällt mir“
6

Der müsste dann ja in der phar stehen. Werde da bei Gelegenheit mal reinschauen. Danke für die Aufklärung.

7

In der phar:///var/www/html/shopware/public/shopware-installer.phar.php/Services/StreamedCommandResponseGenerator.php in Zeile 24 wird der Timeout des Process-Objekts auf 300 Sekunden gesetzt.

1 „Gefällt mir“
8

Kann man eine phar nicht einfach editieren, wie eine php Datei auch? Noch nie gemacht, aber müsste ja eigentlich gehen, da man diese auch erstellen kann.

9

Phar = PHP Archive, eine gezippte PHP Sammlung. Entpacken (ggf. umbenennen .phar → .zip), ändern, wieder packen (ggf. wieder umbenennen).

Nachtrag: Hab mir die Datei mal angesehen, ist scheinbar „nur“ eine riesige PHP-Datei, nicht mal gepackt. Kann man also wohl direkt bearbeiten.

Nachtrag #2: Bei mir steht gleich in Zeile 16

@ini_set('max_execution_time', '300');

vielleicht reicht das ja schon. Weiter unten in der Datei kommt dann der gezippte Teil. Ich kann es leider nicht ausprobieren, bei mir tritt der Fehler nicht auf. Ist das Hosting so langsam, 5min ist ja schon ne lange Zeit?

1 „Gefällt mir“
10

Diese Idee hatte ich natürlich auch direkt, ich muss nur mal prüfen, wann die Datei geladen und eingelesen wird und ob es da ein passendes Zeitfenster für die Bearbeitung gibt. Evtl. stehen ansonsten noch Integrity-Checks im Weg, falls Shopware da was eingebaut hat.

Der Server hat eine ausreichende Ausstattung, ich denke mal die Migrationen dauern bei größeren Datenbanken auf Grund der Indizierung der Tabellen so lange.

11

Siehe oben: Neben der php-Execution-Time muss wohl auch noch das Timeout des Symfony-Commands angepasst werden, der steht auch auf 300.

5 Minuten reichen hier bei Weitem nicht. Die Migrationen von 6.5 auf 6.6 dauern bei meinem Kunden ungefähr 1 Stunde.

1 „Gefällt mir“
12

Ich habe es nun ausprobiert und beide Werte (php max_execution_time sowie den Command-Timeout von Symfony) in der phar-Datei hochgesetzt.

Das Update lief nun erfolgreich durch. Merkwürdig war nur, dass es anscheinend nach der Anzeige von Shopware „Update abgeschlossen“ noch asynchron weiter im Hintergrund gearbeitet hat (es wurden noch Datenbank-Änderungen durchgeführt; sichbtar mit „show processlist“ in mysql).

13

Danke für die ausführliche Antwort. Meine Projekte sind nicht groß genug dafür, wie es aussieht. Freut mich, das es jetzt geklappt hat.

14

Wenn ich mich nicht irre, sind die Migrations inzwischen doch ein eigenständiger Schritt. Beim Ausführen über die CLI sollte der Schritt unendlich lange laufen.

15

Habe ebenfalls das Timeout-Problem beim Update. Wo und auf welchen Werte hast du den Timeout des Symfony-Commandangepasst?
Mich würde auch interessieren, auf welchen Wert du den Max_execution_time Wert gestellt hast?

16

Ich denke, er bezieht sich hierauf.

17

Hmm, leider krieg ich die Datei nicht geöffnet.
Die Fehlermeldung beim Update-Versuch mit Installer lautete:

Fatal error: Uncaught Symfony\Component\Process\Exception\ProcessTimedOutException: The process „‚/usr/bin/php8.2‘ ‚-dmemory_limit=1G‘ ‚/home/www/…/bin/console‘ ‚system:update:finish‘ ‚–no-interaction‘“ exceeded the timeout of 300 seconds. in phar:///home/www/…/public/shopware-installer.phar.php/vendor/symfony/process/Process.php:1157

Irgend eine Idee, wie man diesen Timeout umgehen kann bzw. das Update beenden kann? Für jeden Tipp dankbar …

18

Was heißt „krieg ich nicht geöffnet“? Der Anfang der Datei ist ja normaler Text, sollte also ein gescheiter Editor öffnen können.

19

zwischen -d und memory_limit=1G gehört ein Leerzeichen.

20

So stand es in der Fehlermeldung …