Upload de plus de 2G impossible
Dans les logs nginx : 2014/12/15 17:35:29 [error] 4101#0: *7459 client intended to send too large body: 2598841529 bytes
Option client_max_body_size dans le fichier de conf de l'hôte à changer mais cela ne résoud pas le problème puisqu'une autre erreur émerge : « upstream prematurely closed connection while reading response header from upstream ». Ô joie !
Erreur qui est synchro avec ces erreurs de web2py dans /var/log/uwsgi/uwsgi.log) :
Mon Dec 15 17:44:59 2014 - HARAKIRI !!! worker 2 status !!! Mon Dec 15 17:44:59 2014 - HARAKIRI [core 0] 134.206.10.234 - POST /vidjil/file/upload since 1418661838 Mon Dec 15 17:44:59 2014 - HARAKIRI !!! end of worker 2 status !!! Mon Dec 15 17:45:01 2014 - *** HARAKIRI ON WORKER 2 (pid: 16537, try: 2) *** Mon Dec 15 17:45:01 2014 - HARAKIRI !!! worker 2 status !!! Mon Dec 15 17:45:01 2014 - HARAKIRI [core 0] 134.206.10.234 - POST /vidjil/file/upload since 1418661838 Mon Dec 15 17:45:01 2014 - HARAKIRI !!! end of worker 2 status !!!
Bon, bon… alors augmenter le délai dans l'option harakiri de /etc/uwsgi/web2py.ini aide évidemment. Plus de tels messages d'erreurs. Mais… nginx sort maintenant un « upstream timed out (110: Connection timed out) while reading response header from upstream ». Ouiiin :(
Après l'ajout, dans /etc/nginx/sites-available/web2py de la section suivante : location /vidjil/file/upload { proxy_read_timeout 600; } l'upload ne fonctionne toujours pas sur mon fameux fichier… plus de message d'erreur dans les logs par contre (enfin si il reste toujours des « client intended to send too large body: 2598841526 bytes » erratiques, mais c'est tout)… J'abandonne pour ce soir :(
Juste par curiosité, on a vraiment un fichier de séquences de plus de 2G ?
Non, non je ne me prends pas la tête pour le plaisir, il y a un vrai fichier de plus de 2G (jeux de données des jumeaux). Et les problèmes de timeout je les rencontre sur des fichiers de 2G mais seulement parce que la connexion est très bonne. Avec une moins bonne connexion ils arriveraient sur des fichiers bien moins gros.
ok
Le location /vidjil/file/upload da,s /etc/nginx/sites-available/web2py a été enlevé (ça ne semblait pas résoudre le problème et en causait d'autres). En revanche il a fallu ajouter des client_max_body_size à d'autres endroits de la config pour que ce soit pris en compte par nginx (y compris dans le fichier de conf principal de nginx). Le problème restant correspond à un database is locked, voir la tâche correspondante pour éviter les duplications.
Mikaël, toujours d'actualité ? Marc a pas mal changé l'uploader depuis
Non plus d'actualité : Jack a pu uploader des fichiers de 3G et j'ai pu aussi le faire.
Hmm… j'ai peut-être parlé un peu vite. L'upload était quasiment fini je pensais que c'était gagné mais en fait non. Pas de ticket web2py mais des erreurs dans les logs nginx : upstream prematurely closed connection while reading response header from upstream, client: 134.206.10.234, server: dev.vidjil.org, request: "POST /vidjil/file/upload HTTP/1.1", upstream: "uwsgi://unix:///tmp/web2py-dev.socket:" (ce qui est déjà l'erreur que j'avais il y a 3 mois). Deux essais, deux échecs (depuis le labo).
Marche sous Chrome pas sous FF. C'est ce que disait Marc et c'est vérifié : « http://www.motobit.com/help/scptutl/pa98.htm la plupart des browsers sont limités a 2gb en upload (sauf chrome !!!!)
une solution serait d'utiliser l' API file de hml5 qui permet de slice un upload (mais c'est incompatible avec ie 10) »
On va faire simple : 8695d4b Priorité toujours basse, donc, et ce n'est plus un bug, une limitation. Attendons que les browsers se soient améliorés...
Remonté, on a de nombreux échecs. Ce n'est pas qu'un problème de navigateur. uwsgi se fait de nombreux harakiri à cause de l'upload : sudo grep 'HARAKIRI.*upload' /var/log/uwsgi/uwsgi.log (et ce sont ses seules causes d'harakiri récentes)
C'est très ballot parce que les fichiers semblent uploadés complètement. Le problème vient après (ce n'est donc pas un problème du navigateur, probablement pas du serveur web). Les fichiers sont dans /mnt/upload/tmp tels que transférés par le navigateur web. D'ailleurs ils ne semblent pas automatiquement effacés si l'upload foire !
D'ailleurs le problème survient après que l'indicateur d'upload indique « server check ». Que fait ce server check ?
C'est juste dans database.js, le fichier est tout chargé, mais il se passe quelque chose côté serveur. Quoi ?
Marc m'a dit que le server check s'occupe de copier le fichier au bon endroit (mais c'est fait côté web2py on n'a pas la main dessus). Les logs d'uwsgi montrent ceci : INFO:vidjil: 134.206.239.24/team/LIFL file 17 (1): upload finished (6.44 GB) Wed Mar 25 18:04:17 2015 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /vidjil/file/upload (ip 134.206.239.24) !!! Wed Mar 25 18:04:17 2015 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during POST /vidjil/file/upload (134.206.239.24) IOError: write error
Ce ne serait pas cela ?
http://lists.unbit.it/pipermail/uwsgi/2011-August/002520.html
Normally it is nothing you should care about. If a client disconnect from the webserver, uwsgi will knows it only after data sending. This trigger a sigpipe that uwsgi reports for diagnostic purpose. You can disable it with --ignore-sigpipe
https://www.pythonanywhere.com/forums/topic/721/ Même genre de discussion
The server log comes from your uWSGI workers, which are the ones actually talking to the outside world, and asking your code to respond to requests. They are saying that they sometimes get disconnected from the client half-way through sending a response, and then that causes an error that appears in your error log. This isn't a problem that you can fix, but also it is probably not one you need to worry about. Sometimes, clients disconnect, that is something that happens every day. uWSGI is just a bit over-enthusiastic about logging this. There is an option to switch off SIGPIPE logging in uWSGI which we will investigate.
Ce qui serait normal que le client "déconnecte" au bout d'un gros fichier...
(je passe à autre chose, rdv tout à l'heure)
Après que le serveur indique “upload failed”, il y a toujours des écritures disques (beaucoup) : 8257 be/4 www-data 51.48 M/s 51.44 M/s 0.00 % 90.90 % uwsgi --ini web2py-dev.ini
ça tendrait donc à laisser penser qu'il y a un timeout
Et de façon intéressante (bis) le fichier semble bien pris en compte par le serveur (en ayant changé certains trucs dans le fichier de config) : il indique sa taille mais upload failed (cf.dev.vidjil.org avec l'utilisateur test@vidjil.org)
Le ignore-sigpipe permet certes de retirer le message d'erreur du log mais ne retire pas les autres… INFO:vidjil: 134.206.234.249/team/LIFL file 20 (1): upload finished (6.44 GB) Thu Mar 26 18:36:47 2015 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during POST /vidjil/file/upload (134.206.234.249) IOError: write error
On a eu plusieurs 6GB uploadés depuis... est-ce que cela est toujours d'actualité ?
Non, ce n'est plus d'actualité.
@nobody