Anomalie #4381
ferméProblème d'upload et download sur la valise (nextcloud) April
Ajouté par Frédéric Couchet il y a plus de 4 ans. Mis à jour il y a environ 3 ans.
0%
Description
Sylvain, qui traite les podcasts LAV, me signale ce lundi 30 mars 2020 qu'il n'a pas pu uploader le podcast de LAV sur https://valise.april.org/libre-a-vous message d'erreur "Une erreur inconnue est survenue" à la toute fin du téléversement. il a mis le fichier sur https://www.swisstransfer.com/d/3fb28b75-ba39-4cd2-aeb9-afdec8b4f375
Il m'avait déjà signalé un problème de download la semaine précédente : Sylvain me dit que la récupération du fichier mp3 https://valise.april.org/index.php/s/9AAK6qbtPBeP64R?path=%2F20200324%2FLAV-20200324_CauseCommune_LAV-59%2F01%20-%20Master est en échec, j'ai testé, échec aussi effectivement
Visiblement, la valise a été mise à jour en version 18.0.2 mi-mars, par François.
Fichiers
Capture d’écran de 2020-03-30 11-35-18.png (11,5 ko) Capture d’écran de 2020-03-30 11-35-18.png | François Poulain, 30/03/2020 11:38 | ||
Capture d’écran de 2020-03-30 11-39-18.png (101 ko) Capture d’écran de 2020-03-30 11-39-18.png | François Poulain, 30/03/2020 11:39 | ||
Capture d’écran de 2020-03-30 11-39-40.png (20,6 ko) Capture d’écran de 2020-03-30 11-39-40.png | François Poulain, 30/03/2020 11:40 |
Mis à jour par Frédéric Couchet il y a plus de 4 ans
- Assigné à mis à François Poulain
- Version cible changé de Backlog à Avril 2020
Mis à jour par François Poulain il y a plus de 4 ans
- Fichier Capture d’écran de 2020-03-30 11-35-18.png Capture d’écran de 2020-03-30 11-35-18.png ajouté
Je reproduis l'erreur NC et je n'ai rien vu dans la console js. Par contre je vois bien le retour 503 à la requête donc je suppose que ce n'est pas dissocié du pb de charge.
Mis à jour par François Poulain il y a plus de 4 ans
Mis à jour par Christian P. Momon il y a plus de 4 ans
Loïc suggère de faire un nettoyage via la commande occ.
Sur la liste Nextcloudfr, le 07/04/2020, Thomas MICHEL <thomas@lydra.fr> a écris :
j'espère que tu as accès en console au serveur, sinon ça risque d'être difficile... 1. tu mets ton serveur en maintenance : # sudo -u www-data php -f ./occ maintenance:mode --on 2. tu vides la table de cache : # mysql MariaDB [(none)]> use cloudDatase; MariaDB [(none)]> delete from oc_file_locks where 1; MariaDB [(none)]> exit 3. tu quittes le mode maintenance # sudo -u www-data php -f ./occ maintenance:mode --off 4. tu lances un scan des fichiers (attention ! c'est long. Lances le dans un screen ou tmux) # sudo -u www-data php -f ./occ files:scan --all 5. tu lances un nettoyage de la base # sudo -u www-data php -f ./occ files:cleanup 6. tu forces la resynchronisation chez tes abonnés # sudo -u www-data php -f ./occ maintenance:data-fingerprint Je ne sais pas si toutes ces étapes sont essentielles, mais en cas de gros pépins, c'est ceinture et bretelles
J'ignore si cette procédure est bonne. Peut-être voir dans la documentation officielle.
Mis à jour par Christian P. Momon il y a plus de 4 ans
L'avis de LaurentP sur cette procédure :
cette procédure sert essentiellement à remettre le cache fichiers d'équerre, ce qui peut se faire avec occ scan simplement.
Mis à jour par Quentin Gibeaux il y a plus de 4 ans
- Version cible changé de Avril 2020 à Mai 2020
Mis à jour par Christian P. Momon il y a plus de 4 ans
- Statut changé de Nouveau à En cours de traitement
- Assigné à changé de François Poulain à Christian P. Momon
- mise à jour de modules (#4451) ;
- mise à jour en 18.0.4 (#4451) ;
- resyncho des fichiers :
su - www-data -s /bin/bash -c "php /var/www/valise-new.april.org/occ files:scan --all"
Des tests de téléversements (de 41 Mo à 950 Mo) n'affichent plus aucun message d'erreur.
Mis à jour par Christian P. Momon il y a plus de 4 ans
- Statut changé de En cours de traitement à Résolu
Sur IRC, le 06/05/2020 :
17:29 < cpm_screen> cioccolisa: madix: j'ai fait quelques soins sur la valise, pouvez-vous valider que le téléversesment de fichier ne provoque plus l'affichage de message d'erreur ? :D 17:30 <@cioccolisa> tu as utilisé un produit spécial cuir ? 17:30 * cioccolisa se barre vite 17:31 * cpm_screen se bidonne :))) 17:33 <@cioccolisa> fichier .jpg de gnou téléversé sans problème à l'instant 17:33 < cpm_screen> bien, merci \o/ 17:33 <@cioccolisa> merci à toi
Ticket considéré comme résolu.
Mis à jour par Frédéric Couchet il y a plus de 4 ans
- Statut changé de Résolu à En cours de traitement
Le test de cioccolisa (uploade un fichier .jpg de quelques octets) ne suffit pas à passer https://agir.april.org/issues/4381 en résolu, le problème ne concerne pas l'upload de petits fichiers. Cela concerne l'upload de de fichier de 90 Mo à plus (jusqu'à 1Go, avant que le bug se produise).
Mis à jour par Frédéric Couchet il y a plus de 4 ans
Test avec le fichier https://media.april.org/audio/radio-cause-commune/libre-a-vous/emissions/20200428/libre-a-vous-20200428.ogg (89 Mo) :
- fichier récupéré sur mon laptop
- upload sur https://valise.april.org/libre-a-vous via le navigateur web (en mode non connecté, donc sans compte)
- upload ok
- download du fichier, fichier identique à celui uploadé
Test ok.
Test fait avec un fichier de 240 Mo, test ok aussi.
Test fait avec un fichier de 900 Mo (correspondant à la taille d'un fichier audio Libre à vous ! enregistré par le serveur de la régie). Erreur à la fin et fichier non téléversé, message d'erreur « Expected filesize of 952769860 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 897744896 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. ».
Question donc : quelle est la limite de taille pour le téléversement d'un fichier ?
Mis à jour par Frédéric Couchet il y a plus de 4 ans
Au vu de https://agir.april.org/issues/4153#note-5 la config nginx avait été passé à 512Mo pour client_max_body_size. Mais sur bastion@ dans /etc/nginx/conf.d/local.conf il y a client_max_body_size 1024m;
Donc, la limite serait 1Go, mais je n'ai pas pu téléversé un fichier de 900 Mo. Une limitation sur lamp ?
Mis à jour par Christian P. Momon il y a plus de 4 ans
Frédéric Couchet a écrit :
Au vu de https://agir.april.org/issues/4153#note-5 la config nginx avait été passé à 512Mo
pour client_max_body_size. Mais sur bastion@ dans /etc/nginx/conf.d/local.conf il y a client_max_body_size 1024m;
Donc, la limite serait 1Go, mais je n'ai pas pu téléversé un fichier de 900 Mo. Une limitation sur lamp ?
Alors oui, mais non :D La stratégie de téléversement a changé dans Nextcloud au cours des dernières versions.
Le ticket #4153 concernait l'ancienne stratégie qui consistait à téléverser les fichiers en une seule requête, d'où d'éventuels problèmes de timeout ou de dépassement de limites.
À l'époque, la solution avait été d'augmenter la taille maximale de téléversement dans une requête.
Depuis, Nextcloud utilise une nouvelle stratégie qui consiste à, côté client en Javascript, découper le fichier en morceaux de ~10 Mo et à faire une requête de téléversement par morceau.
Une fois tous les morceaux envoyés, une requête donne l'ordre de tout réassembler puis de déplacer dans le bon dossier.
Dans les logs sur la vm lamp, ça donne ça avec un fichier de 47 Mo :
91.160.XX.XX - - [07/May/2020:23:51:43 +0200] "MKCOL /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120 HTTP/1.0" 201 605 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:44 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/0 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:46 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/10485760 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:48 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/20971520 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:51 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/31457280 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:54 +0200] "PUT /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/41943040 HTTP/1.0" 201 638 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:51:59 +0200] "MOVE /remote.php/dav/uploads/cpm/web-file-upload-1f3a5a384e1d63d79c0cd0d48ffaadb7-1588888303120/.file HTTP/1.0" 201 747 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "GET /index.php/apps/files/ajax/getstoragestats.php HTTP/1.0" 200 983 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "PROPFIND /remote.php/dav/files/cpm/Tests/Stratium-FranceInter-20190509-ITEMA_22057169-1.mp3 HTTP/1.0" 207 1924 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" 91.160.XX.XX - - [07/May/2020:23:52:05 +0200] "GET /index.php/core/preview?fileId=5975&c=08d2830c827806ece81783cb40374ad8&x=250&y=250&forceIcon=0 HTTP/1.0" 200 24750 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0"
On voit bien la suite de « PUT » dans un dossier temporaire et le « MOVE » qui déclenche la reconstitution et le déplacement dans le dossier cible.
Avec cette nouvelle stratégie, plus de problème de timeout ou de dépassement de limite puisque 10 Mo vont plutôt vite à téléverser et que c'est bien en dessous de toute limite raisonnable.
Mis à jour par Christian P. Momon il y a plus de 4 ans
Frédéric Couchet a écrit :
Test fait avec un fichier de 900 Mo (correspondant à la taille d'un fichier audio Libre à vous ! enregistré par le serveur de la régie).
Erreur à la fin et fichier non téléversé, message d'erreur « Expected filesize of 952769860 bytes but read (from Nextcloud client)
and wrote (to Nextcloud storage) 897744896 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side. ».Question donc : quelle est la limite de taille pour le téléversement d'un fichier ?
Vu le commentaire précédent, il n'y a plus de limite de taille :D
Par contre, dans les logs, lors de tes tests, les requêtes semblent très différentes :
86.XX.XX.XX - - [06/May/2020:17:34:56 +0200] "PUT /public.php/webdav/libre-a-vous-20200428.ogg HTTP/1.0" 201 1052 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 86.XX.XX.XX - - [06/May/2020:17:42:52 +0200] "PUT /public.php/webdav/libre-a-vous-20180529.ogg HTTP/1.0" 201 1052 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 86.XX.XX.XX - - [06/May/2020:17:54:52 +0200] "PUT /public.php/webdav/rec_20190702-153000.wav HTTP/1.0" 400 1324 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36" 86.XX.XX.XX - - [06/May/2020:18:05:18 +0200] "PUT /public.php/webdav/rec_20190702-153000.wav HTTP/1.0" 400 1324 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36"
Rien à voir avec le téléversement par morceau décrit ci-dessus.
Quelle méthode utilises-tu pour le téléversement lors de tes tests ?!! Navigateur web (Javascript activé ?), client GNU/Linux, montage webdav… ? (Réponse Fred: tests avec Firefox et Chromium)
Mis à jour par Christian P. Momon il y a plus de 4 ans
- 1,1 Go : ~8 min, sans erreur ;
- 1,4 Go : ~12 min avec erreur « Erreur lors de l'assemblage des blocs, code d'état 504 » mais fichier correct à l'arrivée ;
- 2,3 Go : ~28 min avec erreur « Erreur lors de l'assemblage des blocs, code d'état 504 » mais fichier correct à l'arrivée.
L'erreur 504 survient pour les gros fichiers lors de la phase d'assemblage des morceaux, au bout d'environ 1 minute. Cela peut s'expliquer par le fait que plus il y a de morceaux, plus l'assemblage prend du temps, et donc peut dépasser le timeout du Nginx de bastion :
==> lamp:valise-new.april.org-access.log <== 91.160.XX.XX - - [07/May/2020:23:33:09 +0200] "MOVE /remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file HTTP/1.0" 201 747 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0" ==> bastion:valise-new.april.org.error_log <== 2020/05/07 23:34:09 [error] 11717#11717: *10105899 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 91.160.XX.XX server: valise-new.april.org, request: "MOVE /remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file HTTP/1.1", upstream: "http://172.16.0.11:80/remote.php/dav/uploads/cpm/web-file-upload-0da955617983a8580a955063137cdd82-1588885530594/.file", host: "valise.april.org" ==> bastion:/etc/nginx/nginx.conf <== keepalive_timeout 65;
Une solution serait d'augmenter le timeout du Nginx de bastion, de façon à ce que les fichiers audio de « Libre à vous ! » passent sans erreur.
TODO : Cpm
Mis à jour par Christian P. Momon il y a plus de 4 ans
- le téléversement vers un dossier se fait en mode multi-requêtes ;
- le téléversement vers le même dossier via un lien public se fait en mode mono-requêtes .
Donc le téléversement via un lien public est soumis aux limites de timeout et taille de fichier.
Le ticket #4463 pose la question de pourquoi cette différence et comment la supprimer.
Mis à jour par Christian P. Momon il y a plus de 4 ans
- Lié à Anomalie #4463: Le téléversement via un lien public est fait en mode mono-requête ajouté
Mis à jour par Quentin Gibeaux il y a plus de 4 ans
- Version cible changé de Mai 2020 à Juin 2020
Mis à jour par Quentin Gibeaux il y a plus de 4 ans
- Version cible changé de Juin 2020 à Été 2020
Mis à jour par Quentin Gibeaux il y a environ 4 ans
- Version cible changé de Été 2020 à Septembre 2020
Mis à jour par Quentin Gibeaux il y a environ 4 ans
- Version cible changé de Septembre 2020 à Octobre 2020
Mis à jour par Quentin Gibeaux il y a environ 4 ans
- Version cible changé de Octobre 2020 à Novembre 2020
Mis à jour par Quentin Gibeaux il y a presque 4 ans
- Version cible changé de Novembre 2020 à Décembre 2020
Mis à jour par Quentin Gibeaux il y a presque 4 ans
- Version cible changé de Décembre 2020 à Janvier 2021
Mis à jour par Quentin Gibeaux il y a presque 4 ans
- Version cible changé de Janvier 2021 à Février 2021
Mis à jour par Quentin Gibeaux il y a plus de 3 ans
- Version cible changé de Février 2021 à Mars 2021
Mis à jour par Quentin Gibeaux il y a plus de 3 ans
- Version cible changé de Mars 2021 à Avril 2021
Mis à jour par Quentin Gibeaux il y a plus de 3 ans
- Version cible changé de Avril 2021 à Mai 2021
Mis à jour par Quentin Gibeaux il y a plus de 3 ans
- Version cible changé de Mai 2021 à Juin 2021
Mis à jour par Quentin Gibeaux il y a plus de 3 ans
- Version cible changé de Juin 2021 à Été 2021
Mis à jour par Christian P. Momon il y a plus de 3 ans
Suite à la mise à jour en version 21.0.4 (#5540), reprise des actions.
Pour commencer, le protocole de téléversement est toujours différent suivant qu'on est connecté (multi-requêtes) où que l'on passe par un lien de partage (mono-requête).
Mis à jour par Christian P. Momon il y a plus de 3 ans
- Difficulté changé de 2 Facile à 6 Très difficile
Mode connecté (multi-requêtes)
Côté bastion, configuration d'un timeout 300s au lieu de 60s par défaut, uniquement pour la valise.
Réalisation de plusieurs tests, constat de la disparition des erreurs « Erreur lors de l'assemblage des blocs, code d'état 504 ».
Mis à jour par Christian P. Momon il y a plus de 3 ans
Mode lien de partage (mono-requête)
Sur le bastion, configuration de nginx client_max_body_size de 1024M à 2048M.
Constat d'erreur de téléversement au delà d'une taille approximative de 850Mo.
Des lignes d'erreurs apparaissent dans les logs Nextcloud :
Expected filesize of 1488351239 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 897761280 bytes. Could either be a network problem on the sending side or a problem writing to the storage on the server side.
Après investigation, il s'avère que le téléversement se fait dans /tmp/ où actuellement ~850Mo sont disponibles.
Constat que lors d'un téléversement, le /tmp se remplit et que le message d'erreur dans les logs Nextcloud apparait quand le /tmp/ est plein.
Il faut absolument configurer Nextcloud pour ne pas utiliser /tmp.
En vérifiant, on voit que le Nextcloud est correctement paramétré :
(April) root@lamp:/var/www/valise.april.org/config# grep temp config.php 'tempdirectory' => '/var/www/valise-data/tmp',
Par contre, une note de ticket Nextcloud éclaire la situation : https://github.com/nextcloud/server/issues/19682#issuecomment-654812559
Uploads are processed by PHP before handed to Nextcloud. We are unable to change the location PHP uses to store temporary files used for uploads.
Avec un lien vers la variable à configurer : https://www.php.net/manual/en/ini.core.php#ini.upload-tmp-dir
upload_tmp_dir string The temporary directory used for storing files when doing file upload. Must be writable by whatever user PHP is running as. If not specified PHP will use the system's default.
Il est préconisé de définir un dossier temporaire pour le module PHP d'Apache. Cela a du sens.
Traité dans #5548 pour prendre en compte les directives open_basedir des autres sites web hébergés sur la vm lamp.
Après reconfiguration, des tests confirment l'absence d'erreur.
Mis à jour par Christian P. Momon il y a plus de 3 ans
- Lié à Demande #5548: Sur la vm lamp, configurer un dossier tmp non système pour Apache/PHP ajouté
Mis à jour par Christian P. Momon il y a plus de 3 ans
- Statut changé de En cours de traitement à Résolu
L'ensemble des cas identifiés ont été traités et vérifiés. Fait.