uwsgi invalid request block size

Question

I\'m running uwsgi in emperor mode

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

and getting this error

invalid re         


        

Answer 1

man i m havin same issue; so i did it ... look using 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:application

master = true processes = 33 buffer-size=32768

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

2 - make a serious performance upgrade on nginx ... user www-data;

worker_processes auto; worker_processes 4; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf;

events { worker_connections 4092; multi_accept on; }

http { ##UPGRADE CONFIGS

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; access_log off;

## # Basic Settings ##

sendfile on; tcp_nopush on; tcp_nodelay on; #keepalive_timeout 65; types_hash_max_size 2048; server_tokens off;

server_names_hash_bucket_size 64; # server_name_in_redirect off;

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

## # SSL Settings ##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers on;

## # Logging Settings ##

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

## # Gzip Settings ##

gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied
expired no-cache no-store private auth; 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;

## # Virtual Host Configs ##

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

3 - then ... restart services or reebot server ...

systemctl restart uwsgi & systemctl restart nginx

Answer 2

The correct solution is not to switch to HTTP protocol. You just need to increase the buffer size in uWSGI settings.

buffer-size=32768

or in commandline mode:

-b 32768

Quote from official documentation:

By default uWSGI allocates a very small buffer (4096 bytes) for the headers of each request. If you start receiving “invalid request block size” in your logs, it could mean you need a bigger buffer. Increase it (up to 65535) with the buffer-size option.

If you receive ‘21573’ as the request block size in your logs, it could mean you are using the HTTP protocol to speak with an instance speaking the uwsgi protocol. Don’t do this.

From here: https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html

Answer 3

I aslo ran into same issue while following some tutorial. The problem was that I set the option socket = 0.0.0.0:8000 instead of http = 0.0.0.0:8000. socket option intended to be used with some third-party router (nginx for instance), while when http option is set uwsgi can accept incoming HTTP requests and route them by itself.

Answer 4

I could fix it adding --protocol=http to the uwsgi

Answer 5

I ran into the same issue trying to run it under nginx and was following the docs here. It is important to note that once you switch to nginx you have to make sure you are not trying to access the app on the port specified by the --socket param but rather the "listen" port in nginx.conf. Although your problem is described differently the title matches exactly the issue I had.

Answer 6

As pointed out in another comment from the docs:

If you receive ‘21573’ as the request block size in your logs, it could mean you are using the HTTP protocol to speak with an instance speaking the uwsgi protocol. Don’t do this.

If you are using Nginx, this will occur if you are have this configuration (or something similarly odd):

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

this is speaking HTTP to uWSGI (which makes it grumpy). Instead, use:

uwsgi_pass unix:/path/to/socket.sock;