uwsgi tamaño de bloque de solicitud no válido

142

Estoy ejecutando uwsgi en modo emperador

uwsgi --emperor /path/to/vassals/ --buffer-size=32768

y obteniendo este error

invalid request block size: 21327 (max 4096)...skip

¿¿Qué hacer?? También probé -b 32768

Kartik Rokde
fuente
1
El tamaño del búfer obviamente sigue siendo el valor predeterminado (4096), asegúrese de estar trabajando en la instancia correcta. También puedes escribir "-b 32k". También asegúrese de que esta opción (tamaño de búfer) no esté establecida en algún archivo de configuración.
zakinster
No hay archivo de configuración. Todavía no funciona :(
Kartik Rokde
8
uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html está intentando conectarse a un socket uwsgi utilizando el protocolo http, además de esto, las opciones especificadas para el emperador no se heredan, solo es un administrador de procesos
roberto
@zakinster Por alguna razón, el formato de valor con kno funcionó para mí. Tenía que proporcionar el número completo. No puedo encontrar ningún puntero sobre los formatos que puedes usar aquí.
famousgarkin

Respuestas:

207

También me encontré con el mismo problema mientras seguía un tutorial. El problema fue que configuré la opción en socket = 0.0.0.0:8000lugar de http = 0.0.0.0:8000. socketopción pensada para ser utilizada con algún enrutador de terceros (nginx por ejemplo), mientras que cuando la httpopción está configurada, uwsgi puede aceptar solicitudes HTTP entrantes y enrutarlas por sí mismo.

Palasatia
fuente
55
Solo me gustaría comentar sobre esto: uwsgi tiene las opciones "http", "http-socket" y "socket". Quería llamar a scripts cgi python; "zócalo" fue la respuesta.
NuclearPeon
En el archivo de configuración de Nginx, podemos usar esto: include / etc / nginx / uwsgi_params; uwsgi_pass django_upstream;
mennanov
3
No es la solución correcta. ¿Qué pasa si queremos unix zócalos?
Farsheed
2
@Farsheed, acabo de describir por qué OP está viendo este error. Cómo solucionarlo depende completamente de usted. Puede ser socket = /tmp/myapp.socko http = 0.0.0.0:8000lo que sea, según sus necesidades.
Palasaty
1
Si bien esta respuesta podría resolver el problema en algunas situaciones, creo que la respuesta correcta en el caso general es la proporcionada por @Farsheed a continuación.
Augusto Destrero
142

La solución correcta es no cambiar al protocolo HTTP. Solo necesita aumentar el tamaño del búfer en la configuración de uWSGI.

buffer-size=32768

o en modo de línea de comandos:

-b 32768

Cita de la documentación oficial:

Por defecto, uWSGI asigna un búfer muy pequeño (4096 bytes) para los encabezados de cada solicitud. Si comienza a recibir "tamaño de bloque de solicitud no válido" en sus registros, podría significar que necesita un búfer más grande. Aumente (hasta 65535) con la opción de tamaño de búfer.

Si recibe '21573' como el tamaño de bloque de solicitud en sus registros, podría significar que está utilizando el protocolo HTTP para hablar con una instancia que habla el protocolo uwsgi. No hagas esto.

Desde aquí: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

Farsheed
fuente
1
A veces tiene que usar el protocolo http, ya que los sockets unix solo están disponibles en la máquina local. Considere una situación en la que tiene varias máquinas y un equilibrador separado encima de ellas: debe usarlas http-socketaquí.
Palasaty
@Palasaty o un socket IP y uwsgiprotocolo, entonces también puede obtener el mismo error que OP
Andrei
2
@Palasaty, en cualquier causa, arreglar el tamaño del búfer solucionará el problema.
Farsheed
Cuando usaba nginx como proxy inverso, tenía que usar http-socket. Cualquier otra cosa dio "502 Bad Gateway", incluso cuando se aumentó el tamaño del búfer.
Hubro
En cuanto a la documentación citada "Si recibe '21573' como el tamaño del bloque de solicitud en sus registros, podría significar que está utilizando el protocolo HTTP para hablar con una instancia que habla el protocolo uwsgi. No haga esto". Así que está claro que la sugerencia es incorrecta ... Además, el usuario @Kartic ya ha intentado usar la opción "-b" ...
LittleEaster
14

Me encontré con el mismo problema al intentar ejecutarlo en nginx y seguí los documentos aquí . Es importante tener en cuenta que una vez que cambie a nginx, debe asegurarse de no intentar acceder a la aplicación en el puerto especificado por --socket param, sino más bien al puerto "escuchar" en nginx.conf. Aunque su problema se describe de manera diferente, el título coincide exactamente con el problema que tuve.

Paulo SantAnna
fuente
Sí, me encontré con lo mismo. en otras palabras, recibí un error cuando enrosqué el puerto localmente, mientras que pude navegar con éxito a la 'ubicación' de mi proxy inverso wsgi como se especifica en mi 'nginx.conf', porque el protocolo del servidor wsgi en mi socket elegido era wsgi y no http
danyamachine
14

Podría arreglarlo agregando --protocol = http al uwsgi

ajamardo
fuente
2
¿Cómo puedo configurar esto en el archivo ini de la configuración de uWSGI? Mi configuración funciona con su sugerencia pero solo en la línea de comando.
Henry Lynx
2
@HenryLynx, solo agregue protocol=httpa su .iniarchivo
151291
7

Este error se muestra cuando el servidor uWSGI está utilizando el uwsgiprotocolo y uno intenta acceder a él a través del httpprotocolo mediante curlun navegador web directamente. Si puede, intente configurar su servidor uWSGI para usar el httpprotocolo, de modo que pueda acceder a él a través del navegador web o curl.

En caso de que no pueda (o no quiera) cambiarlo, puede usar un proxy inverso (por ejemplo nginx) frente al servidor uWSGI local o remoto, consulte https://uwsgi-docs.readthedocs.org/en/latest/Nginx .html

Si le parece demasiado trabajo, pruebe el uwsgi-toolspaquete python:

$ pip install uwsgi-tools

$ uwsgi_curl 10.0.0.1:3030

También hay un servidor proxy inverso simple uwsgi_proxysi necesita acceder a sus aplicaciones a través del navegador web, etc. Vea una respuesta más amplia https://stackoverflow.com/a/32893520/179581

Andrei
fuente
2

Como se señaló en otro comentario de los documentos:

Si recibe '21573' como el tamaño de bloque de solicitud en sus registros, podría significar que está utilizando el protocolo HTTP para hablar con una instancia que habla el protocolo uwsgi. No hagas esto.

Si está utilizando Nginx, esto ocurrirá si tiene esta configuración (o algo similar):

proxy_pass http://unix:/path/to/socket.sock

esto está hablando de HTTP a uWSGI (lo que lo hace gruñón). En cambio, use:

uwsgi_pass unix:/path/to/socket.sock;
Demitri
fuente
0

el hombre tengo el mismo problema; así que lo hice ... mira usando UWSGI + DJANGO + NGINX + REACT +

1 - nano /etc/uwsgi/sites/app_plataform.ini [uwsgi]

DJANGO_SETTINGS_MODULE = app_plataform.settings env = DJANGO_SETTINGS_MODULE settings.configure ()

chdir = / home / app_plataform home = / root / app_plataform module = prometheus_plataform.wsgi: aplicación

maestro = procesos verdaderos = 33 tamaño del búfer = 32768

socket = /home/app_plataform/app_plataform.sock chmod-socket = 777 vacuum = true

2 - realice una actualización seria de rendimiento en nginx ... usuario www-data;

trabajador_procesos auto; procesos_trabajadores 4; pid /run/nginx.pid; incluir /etc/nginx/modules-enabled/*.conf;

eventos {trabajador_conecciones 4092; multi_accept on; }

http {## CONFIGURACIÓN DE ACTUALIZACIÓN

client_body_buffer_size 16K; client_header_buffer_size 16k; client_max_body_size 32m; #large_client_header_buffers 2 1k;

client_body_timeout 12; client_header_timeout 12; keepalive_timeout 15; send_timeout 10; acceso_log desactivado;

## # Ajustes básicos ##

enviar archivo; tcp_nopush en; tcp_nodelay on; #keepalive_timeout 65; types_hash_max_size 2048; server_tokens off;

server_names_hash_bucket_size 64; # server_name_in_redirect desactivado;

incluir /etc/nginx/mime.types; default_type application / octet-stream;

## # Configuración SSL ##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dejar caer SSLv3, ref: POODLE ssl_prefer_server_ciphers en;

## # Configuración de registro ##

access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log;

## # Configuración de Gzip ##

gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
expirado sin caché no-store autenticación privada; gzip_types text / plain application / x-javascript text / xml text / css application / xml; gzip_vary on;

#gzip_proxied any; #gzip_comp_level 6; gzip_buffers 16 8k; gzip_http_version 1.1; #gzip_types text / plain text / css application / json application / javascript text / xml application / xml application / xml + rss text / javascript;

## # Configuraciones de host virtual ##

incluir /etc/nginx/conf.d/ .conf; incluir / etc / nginx / sites-enabled / ; }

3 - luego ... reinicie los servicios o reebot server ...

systemctl restart uwsgi y systemctl restart nginx

Renan Moura
fuente