Nextcloud Download bricht ab

Virinum · Apr 18th 2019

Hallo zusammen!

Ich verwende das Webhosting EiWoMiSau. Hierauf habe ich nextcloud installiert.

Jetzt habe ich nur folgendes Problem. Der Download von Dateien oder Ordnern bricht ab:

Bei einer 100 Mbit/s Anbindung nach ca. 6,2 GB
Bei einer 50 Mbit/s Anbindung nach ca. 3 GB

Immer nach ca. 8 Minuten. Mal nach 7 Minuten 22 Sekunden und mal nach 8 Minuten 45 Sekunden.

Bei Leistungen steht "PHP Execution Time: 60s (120s Webhosting 8000)". Aber 8 Minuten sind ja eindeutig mehr als 60 bzw. 120 Sekunden.

Gibt es da noch irgendein anderes Limit oder ein Timeout, das ich einstellen kann? Oder hat es was mit dem Output-Buffering zu tun? Bin an der Stelle leider mit meinem Latein am Ende.

Vielen Dank schon mal für eure Tipps!

KB19 · Apr 18th 2019

Passiert das wirklich nur beim Download oder auch beim Upload?

Virinum · Apr 19th 2019

Nur beim Download.

Mittlerweile habe ich rausgefunden, dass es nicht an nextcloud selber liegt.

Zum Test habe ich mal folgendes Script ausprobiert:

PHP: 10GB.php

<?php
$file = '10GB.zip';

if (ob_get_level()) {
  ob_end_clean();
}

if (file_exists($file)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename($file).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($file));
    readfile($file);
    exit;
}
?>

Display More

Hier ist das Verhalten genau so wie bei Nextcloud. Wenn meine Leitung schnell genug ist, schaffe ich es auch die Datei vollständig runterzuladen. Ist sie es aber nicht, bricht der Download ab.

CmdrXay · Apr 19th 2019

Hay,

und wenn Du das File mal direkt vom Webspace herunterlädtst, also ohne php-Kram drumherum? Damit kannst Du ausschließen, dass es am PHP liegt. Wie sieht es aus, wenn ein anderer oder Du von einem anderen Ort das File holt? Damit kannst Du ausschließen, dass es an Deiner Seite liegt. Wenn es "nackig" von einem anderen Ort dieselben Probleme macht, dann würde ich mal den Support anfragen, denn dann kann es nur noch am Webhost selbst liegen.

CU, Peter

Virinum · Apr 19th 2019

Danke für deine Antwort.

Das Runterladen von der 10GB.zip selber funktioniert. Sobald aber PHP das ganze ausliefern soll, gibt es dieses Problem.

http://example.com/10GB.zip:

http://example.com/10GB.php:

Was meinst du genau mit "von einem anderen Ort das File holen"? Von einem anderen Anschluss runterladen? Oder von einem anderen Webhost mal testen?

Bensen · Apr 19th 2019

Quote from Virinum

Was meinst du genau mit "von einem anderen Ort das File holen"? Von einem anderen Anschluss runterladen? Oder von einem anderen Webhost mal testen?

Ja von einem anderen Anschluss, jedoch

bricht der Download ja ohne PHP nicht mehr ab. Deshalb sollte ein Fehler deines Anschlusses auszuschließen sein.

Welche PHP Konfiguration nutzt du im WCP und wie liefertst du die Daten aus, per apache oder nginx?

Ansonsten würde ich, wie Peter, den Support kontaktieren.

tab · Apr 19th 2019

Da tippe ich mal, dass du entweder das memory_limit oder die max_execution_time überschreitest, Die max_execution_time ist ja nicht die "echte" Zeit, die man mit einer Stoppuhr misst. Passt ja auch dazu, dass du mit einer schnelleren Verbindung mehr von der Datei laden kannst, bevor der Download abbricht.

Virinum · Apr 19th 2019

Der Anschluss spielt dabei keine Rolle.

Quote from Bensen

Welche PHP Konfiguration nutzt du im WCP und wie liefertst du die Daten aus, per apache oder nginx?

PHP 7.2.17 FastCGI von Apache bedient.

Ich probiere jetzt mal FPM. Vielleicht bringt das ja einen Unterschied. Ansonsten frage ich mal beim Support nach.

Quote from tab

Da tippe ich mal, dass du entweder das memory_limit oder die max_execution_time überschreitest,

In wie weit haben denn diese Werte Einfluss darauf? Das memory_limit ist 512 MB. Aber ich bekomme ja mehr als 512 MB runtergeladen. Und wie geht PHP denn mit der max_execution_time um? Falls du mir das erklären könntest, wäre das echt super.

Kraeutergarten · Apr 19th 2019

Villeicht liegt es am proxy_read_timeout von nginx.

Bensen · Apr 19th 2019

Die max_execution_time legt die maximale Zeit in Sekunden zum Ausführen eines Scripts fest, bevor der Prozess vom System gekillt wird.

Diese PHP Werte sollten aber für den Download keine allzu große Rolle spielen. Zur Not kannst du, um auf Nummer sicher zugehen, das PHP error reporting aktivieren (am besten inkl. logging) und schauen ob bei Abbruch des Downloads Fehler angezeigt werden.

tab · Apr 19th 2019

Quote from Bensen

Die max_execution_time legt die maximale Zeit in Sekunden zum Ausführen eines Scripts fest, bevor der Prozess vom System gekillt wird.

Diese PHP Werte sollten aber für den Download keine allzu große Rolle spielen. Zur Not kannst du, um auf Nummer sicher zugehen, das PHP error reporting aktivieren (am besten inkl. logging) und schauen ob bei Abbruch des Downloads Fehler angezeigt werden.

Aber:

Quote

Hinweis:
Die set_time_limit()-Funktion und die max_execution_time Konfigurationsdirektive beschränken nur die Ausführungszeit des Skripts selbst. Zeit die für Aktivitäten außerhalb des Skripts aufgebracht wird wie z.B. die Ausführung von Systemaufrufen mit system(), Streamoperationen, Datenbankabfragen usw. werden nicht in die Berechnung der Ausführungszeit mit einbezogen.

Nix genaues ist da leider nicht zu finden und finde ich auch sonst auf die Schnelle nirgends. Notfalls ausprobieren. Aber zwischen den Zeilen würde ich lesen - wegen "werden nicht in die Berechnung der Ausführungszeit mit einbezogen" - dass hier nicht stur die reale Ausführungszeit des gesamten Downloadvorgangs genommen wird.

Virinum · Apr 19th 2019

Danke für die Erklärungen!

Ich habe mittlerweile mal mit FPM statt FastCGI getestet. Und tatsächlich tritt hier das Problem nicht auf. Mein Problem ist damit also "gelöst".

Trotzdem interessiert es mich noch, wieso das mit FastCGI nicht funktioniert. Ich frage dazu mal beim Support nach und gebe dann Bescheid.

Vielen Dank für eure Hilfe.

Virinum · Apr 20th 2019

Ich habe vom Support eine Antwort erhalten:

Quote from netcup Team

FPM steht für "FastCGI Process Manager". Dabei wird nicht für jedes PHP-Skript ein neuer Interpreter-Job gestartet, sondern mehrere FastCGI Prozesse sind im Hintergrund aktiv und warten auf Eingaben/Aufträge vom Webserver. Dadurch ist die Ausführung verlässlicher, da die Prozesse nicht vom Webserver abhängig sind (und auch nicht mit den Rechten des Webservers, sondern des PHP-FPM Benutzers ausgeführt werden).

Virinum · Apr 24th 2019

Das umstellen auf FPM hat das ganze leider nicht behoben, sondern nur die Grenze der mindestens vorhandenen Downloadgeschwindigkeit etwas nach unten gesetzt.

Folgendes Verhalten kann ich beim Download von https://vm0.de/5GB.php beobachten:

5 GB Datei über 50 Mbit/s: nach ca. 14 Minuten erfolgreich
5 GB Datei über 25 Mbit/s: nach ca. 5,5 Minuten abgebrochen

Im Log finde ich folgende Fehlermeldungen:

Code: error_log

[Wed Apr 24 09:54:45.924903 2019] [proxy_fcgi:error] [pid 32264] [client XXX.XXX.XXX.XXX] AH01068: Got bogus version 166
[Wed Apr 24 09:54:45.924972 2019] [proxy_fcgi:error] [pid 32264] (22)Invalid argument: [client XXX.XXX.XXX.XXX] AH01075: Error dispatching request to : (passing brigade to output filters)

Ich hab auch schon versucht den Support zu kontaktieren, der stellt sich aber quer:

Quote from netcup Support

Bitte haben Sie dafür Verständnis, dass wir keinen Support zu Ihren Inhalten und Anwendungen anbieten können, da es schlicht unendlich viel Software, Versionen, Plugins und Optionen als Möglichkeiten gibt

Dies würde schlicht jeglichen sinnvollen Supportrahmen sprengen.

Wobei ich das starke Gefühl habe, dass meine Mail nur sehr halbherzig gelesen wurde. Es geht ja nicht konkret um eine Software, sondern um eine Grundfunktion von PHP. Aber ich bleibe da dran.

Ehrlich gesagt habe ich keine Ahnung, was ich mir jetzt von euch erhoffe. Ich denke nämlich, dass nur der Support kann da wirklich was reißen. Aber vielleicht hat ja jemand eine Erleuchtung.

JKMakowka · Apr 25th 2019

Mal geraten: vielleicht hilft die "Serve static files directly by nginx" Funktion unter "Apache & nginx Settings"? Standardmäßig ist das deaktiviert.

Virinum · Apr 25th 2019

Quote from JKMakowka

vielleicht hilft die "Serve static files directly by nginx" Funktion unter "Apache & nginx Settings"?

Es handelt sich dabei ja nicht um eine statische Datei, sonder um eine Datei, die durch PHP "durchgeschliffen" wird. Also bringt die Einstellung leider nichts. Aber danke für deinen Tipp.

Bin übrigens nach wie vor mit dem Support in Kontakt. Das Problem kann dort nachgestellt werden. Jedoch ist im Moment noch von einem Timeout von FastCGI die Rede. Dagegen spricht aber meiner Meinung nach, was ich oben erwähnt habe:

Quote from Virinum

5 GB Datei über 50 Mbit/s: nach ca. 14 Minuten erfolgreich
5 GB Datei über 25 Mbit/s: nach ca. 5,5 Minuten abgebrochen

Ich halte euch hier weiter auf dem Laufenden.

Virinum · Apr 25th 2019

Ganz verstehe ich die Antwort vom Support nicht, aber sie klingt irgendwie plausibel:

Quote from netcup Support

Es handelt sich um einen Timeout von FastCGI nicht direkt von PHP. Der Fehler wird aber nicht durch einen ungenügenden Parameter in der Config erzeugt sondern durch den Client. Dieser scheint die Verbindung zu schnell zu schließen, bevor der Server die Anfrage abschließend beantworten kann.

Konkret geht es um diesen Teil des Codes in mod_fcgid:

/* Now pass any remaining response body data to output filters */
if ((rv = ap_pass_brigade(r->output_filters,
brigade_stdout)) != APR_SUCCESS) {
if (!APR_STATUS_IS_ECONNABORTED(rv)) {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, rv, r,
"mod_fcgid: ap_pass_brigade failed in "
"handle_request_ipc function");
}

Es ist also nicht durch serverseitige Einstellungen zu regeln.

Display More

Also abschließend lässt sich sagen: Mit Apache klappt es einfach nicht. Mit "FPM served by nginx" jedoch schon. Ich verwende jetzt also nginx. Jetzt muss ich nur noch rausfinden, wie ich die Meldung weg bekomme:

Quote from nextcloud

PHP scheint zur Abfrage von Systemumgebungsvariablen nicht richtig eingerichtet zu sein. Der Test mit getenv("PATH") liefert nur eine leere Antwort zurück. Bitte die Installationsdokumentation auf Hinweise zur PHP-Konfiguration durchlesen, sowie die PHP-Konfiguration Deines Servers überprüfen, insbesondere dann, wenn PHP-FPM eingesetzt wird.

nipfuh · Mar 24th 2021

Moin zusammen

da FPM bei neueren PHP Versionen nicht mehr verfügbar ist, wollte ich fragen, ob vielleicht jemand von euch eine Lösung gefunden hat, die ohne FPM auskommt?

statnc · Apr 19th 2021

Quote from nipfuh

Moin zusammen

da FPM bei neueren PHP Versionen nicht mehr verfügbar ist, wollte ich fragen, ob vielleicht jemand von euch eine Lösung gefunden hat, die ohne FPM auskommt

hatte dasselbe Problem und habe es letzlich hinbekommen mit den Einstellungen

php5.6.40, FastCGI, 1024M Memory Limit, 360 Execution Time.

Download von Dateien bis 3GB und Laufzeit ca. 8 Minuten (also deutlich mehr als 360 Sekunden!) hat funktioniert.

Das folgende Script hat mit 90 Sekunden Execution time immer bei ca. 1024MB Download abgebrochen bei ca, 5.5 MB/s

Das hatte mich irritiert wegen 1024MB Memory Limit wobei der Download in Chunks ja unabhängig vom Memory Limit sein sollte.

Ich habe keine Ahnung wieso es bei 360 Sekunden nun völlig problemlos geht - obwohl der Download deutlich länger dauert. Vermutlich sind die Skript-Laufzeiten nicht in "echten" Sekunden zu sehen. Andere Laufzeiten hab ich nicht getestet.

Eventuell würde bei größeren Dateien die 6-Minuten-Laufzeit dann den Download auch wieder killen.

Ich bin froh, dass es jetzt funktioniert mit meinen Dateien (max. 3 GB wie gesagt). Das hat mich Stunden gekostet.

Code

$size = intval(sprintf("%u", filesize($datei_userdownload)));
$chunksize = 1024 * 1024;
header('Pragma: public');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Cache-Control: private', false);
header('Content-Transfer-Encoding: binary');
header("Content-Disposition: attachment; filename=" . $datei);
header("Content-Type: " . $MimeTypes[$DateiExt]);
header('Content-Length: ' . $size);

if ($size > $chunksize) {
 $handle = fopen($datei_userdownload, 'rb');
 while (!feof($handle)) {
   $buffer = fread($handle, $chunksize);
   echo $buffer;
   ob_flush();
   flush();
 }
 fclose($handle);
 exit;
} else {
 readfile($datei_userdownload);
 exit;
}

Display More

Virinum · Apr 19th 2021

Aktuelle Versionen von Nextcloud brauchen mindestens PHP 7.4. Wie hast du es denn mit PHP 5.6 zum laufen bekommen? Mal ganz davon abgesehen, dass der Support für PHP 5.6 seit über zwei Jahren abgelaufen ist.

Tags