Project

General

Profile

Anomalie #4381

Problème d'upload et download sur la valise (nextcloud) April

Added by Frédéric Couchet about 4 years ago. Updated over 2 years ago.

Status:
Fermé
Priority:
Normale
Assignee:
Christian P. Momon
Category:
-
Target version:
Start date:
03/30/2020
Due date:
% Done:

0%

Estimated time:
Difficulté:
6 Très difficile

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.


Files


Related issues

Related to valise.chapril.org - Anomalie #4463: Le téléversement via un lien public est fait en mode mono-requêteRejeté05/08/2020

Actions
Related to Admins - Demande #5548: Sur la vm lamp, configurer un dossier tmp non système pour Apache/PHPRésolu08/24/2021

Actions

History

#1

Updated by Frédéric Couchet about 4 years ago

  • Assignee set to François Poulain
  • Target version changed from Backlog to Avril 2020
#2

Updated by François Poulain about 4 years ago

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.

#4

Updated by Christian P. Momon about 4 years ago

Loïc suggère de faire un nettoyage via la commande occ.

Sur la liste Nextcloudfr, le 07/04/2020, Thomas MICHEL <> 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.

#5

Updated by Christian P. Momon about 4 years ago

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.

#6

Updated by Quentin Gibeaux almost 4 years ago

  • Target version changed from Avril 2020 to Mai 2020
#7

Updated by Christian P. Momon almost 4 years ago

  • Status changed from Nouveau to En cours de traitement
  • Assignee changed from François Poulain to Christian P. Momon
Quelques opérations de soins sur la valise :
  • 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.

#8

Updated by Christian P. Momon almost 4 years ago

  • Status changed from En cours de traitement to 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.

#9

Updated by Frédéric Couchet almost 4 years ago

  • Status changed from Résolu to 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).

#10

Updated by Frédéric Couchet almost 4 years ago

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 ?

#11

Updated by Frédéric Couchet almost 4 years ago

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 ?

#12

Updated by Christian P. Momon almost 4 years ago

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.

#13

Updated by Christian P. Momon almost 4 years ago

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)

#14

Updated by Christian P. Momon almost 4 years ago

Tests refaits via l'interface web :
  • 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

#15

Updated by Christian P. Momon almost 4 years ago

Suite à plusieurs tests avec Fred, on constate que :
  • 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.

#16

Updated by Christian P. Momon almost 4 years ago

  • Related to Anomalie #4463: Le téléversement via un lien public est fait en mode mono-requête added
#17

Updated by Quentin Gibeaux almost 4 years ago

  • Target version changed from Mai 2020 to Juin 2020
#18

Updated by Quentin Gibeaux almost 4 years ago

  • Target version changed from Juin 2020 to Été 2020
#19

Updated by Quentin Gibeaux over 3 years ago

  • Target version changed from Été 2020 to Septembre 2020
#20

Updated by Quentin Gibeaux over 3 years ago

  • Target version changed from Septembre 2020 to Octobre 2020
#21

Updated by Quentin Gibeaux over 3 years ago

  • Target version changed from Octobre 2020 to Novembre 2020
#22

Updated by Quentin Gibeaux over 3 years ago

  • Target version changed from Novembre 2020 to Décembre 2020
#23

Updated by Quentin Gibeaux over 3 years ago

  • Target version changed from Décembre 2020 to Janvier 2021
#24

Updated by Quentin Gibeaux about 3 years ago

  • Target version changed from Janvier 2021 to Février 2021
#25

Updated by Quentin Gibeaux about 3 years ago

  • Target version changed from Février 2021 to Mars 2021
#26

Updated by Quentin Gibeaux about 3 years ago

  • Target version changed from Mars 2021 to Avril 2021
#27

Updated by Quentin Gibeaux almost 3 years ago

  • Target version changed from Avril 2021 to Mai 2021
#28

Updated by Quentin Gibeaux almost 3 years ago

  • Target version changed from Mai 2021 to Juin 2021
#29

Updated by Quentin Gibeaux almost 3 years ago

  • Target version changed from Juin 2021 to Été 2021
#30

Updated by Christian P. Momon over 2 years ago

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).

#31

Updated by Christian P. Momon over 2 years ago

  • Difficulté changed from 2 Facile to 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 ».

#32

Updated by Christian P. Momon over 2 years ago

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.

#33

Updated by Christian P. Momon over 2 years ago

  • Related to Demande #5548: Sur la vm lamp, configurer un dossier tmp non système pour Apache/PHP added
#34

Updated by Christian P. Momon over 2 years ago

  • Status changed from En cours de traitement to Résolu

L'ensemble des cas identifiés ont été traités et vérifiés. Fait.

#35

Updated by Quentin Gibeaux over 2 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF