How to disable request logging in Django and uWSGI? - django

My uWSGI logs are full of entries like this for every request:
localhost [pid: 4029|app: 0|req: 1/1] 127.0.0.1 () {48 vars in 906
bytes} [Wed Mar 23 18:35:38 2016] GET / => generated 94847 bytes in
1137 msecs (HTTP/1.1 200) 4 headers in 224 bytes (1 switches on core
0)
I'm not sure if it's uWSGI spamming them or Django. How can I disable the request logging?

What does your uwsgi.ini look like? That's where you'd want to disable logging.
Set: disable-logging=True
Here's the docs:
http://uwsgi-docs.readthedocs.org/en/latest/Options.html#disable-logging

Or from the console with:
uwsgi --disable-logging

Related

'no python application found' in Django

I tried to deploy my Django project on server with uwsgi.
I can initial uwsgi with uwsgi --ini conf/uwsgi.ini
But when I tried to visit the website, I got this error
--- no python application found, check your startup logs for errors ---
[pid: 11228|app: -1|req: -1/1] 127.0.0.1 () {46 vars in 946 bytes} [Mon Nov 28 17:06:37 2022] GET / => generated 21 bytes in 0 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
I put my repo at https://github.com/dolphinfafa/MyLife
Anyone knows how to resolve this?

Add Username and Client IP Address in the Django manage.py runserver default output

Could anybody please help me, how to add Username and Clinet IP Address in the Django manage.py runserver default output.
currently I am seeing:
[01/Jul/2019 11:34:27] "GET / HTTP/1.1" 200 237
expected result:
[pid: 10|app: 0|req: 1/2] 10.176.123.254 (Logged in username/email) {86 vars in 4942 bytes} [Mon Jul 1 06:08:37 2019] GET / => generated 291 bytes in 1160 msecs (HTTP/1.1 200) 7 headers in 250 bytes (1 switches on core 0)

nginx & uwsgi deploy django app get SIGPIPE 502 error

I use nginx and uwsgi deploy my django webapp, the start few minutes all things well but after some time the ngnix will report 502 error and I check the uwsgi stderr log. there are some error marked => generated & SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request such as blow error message:
>[pid: 27427|app: 0|req: 1/1] 10.209.78.30 () {38 vars in 1030 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 16018 bytes in 1428 msecs (HTTP/1.1 200) 6 headers in 157 bytes (1 switches on core 0)
Mon Sep 29 15:46:03 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.209.78.30) !!!
Mon Sep 29 15:46:03 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.209.78.30)
IOError: write error
[pid: 27425|app: 0|req: 1/2] 10.209.78.30 () {38 vars in 2050 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 0 bytes in 3578 msecs (HTTP/1.1 200) 6 headers in 0 bytes (0 switches on core 0)
Mon Sep 29 15:46:04 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.217.95.130) !!!
Mon Sep 29 15:46:04 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.217.95.130)
IOError: write error
[pid: 27426|app: 0|req: 1/3] 10.217.95.130 () {38 vars in 1871 bytes} [Mon Sep 29 15:46:00 2014] GET blabla...(just request url address) => generated 0 bytes in 4415 msecs (HTTP/1.1 200) 6 headers in 0 bytes (0 switches on core 0)
Mon Sep 29 15:46:05 2014 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request blabla...(just request url address) (ip 10.217.95.130) !!!
Mon Sep 29 15:46:05 2014 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 287] during GET blabla...(just request url address) (10.217.95.130)
IOError: write error
I replace the request url by blabla...
My nginx.conf is bleow:
location / {
add_header "Access-Control-Allow-Origin" "*";
add_header "Access-Control-Allow-Methods" "GET, OPTIONS";
add_header "Access-Control-Allow-Headers" "origin, authorization, accept";
uwsgi_pass unix:///tmp/djangoapp.sock;
include uwsgi_params;
}
uWSGI launch command:
uwsgi --socket /tmp/djangoapp.sock -p 10 --wsgi-file /opt/graphite/conf/graphite_wsgi.py --chmod-socket=666

Django app works via manage.py runserver but page rendered via mod_uwsgi fails to refer to static elements

I am at the end of my rope here... and plan to start digging into Django source code to figure this out.
I have a Django app that has been created in the standard fashion via start project. So far I have been testing it via "python manage.py runserver 8081".
Now I am trying to put this behind Nginx using mod_uwsgi.
So I test it using the excellent instructions over here.
My ini file looks as follows:
uwsgi]
chdir=<path_to_my_project>
module=<application>.wsgi:application
pidfile=/tmp/<pid_file_name>
max-requests=5000
daemonize=/var/log/uwsgi/<log_file_name>
env=DJANGO_SETTINGS_MODULE=<application>.settings
http-socket=127.0.0.1:50000
So I start the app using:
uwsgi --ini uwsgi.ini
All seems to look good:
Log file at "/var/log/uwsgi/" created: Looks good.
Directory is changed: Looks good. Log file indicates so.
Module is loaded: Assume that it has... I don't see any error message in the logs.
pidfile is created: Looks good. I do see the correct PID number in the file.
Tested the closing of the process via SIGINT.
Listening at http-socket: Looks good.
PROBLEM:
When I hit the site via http://site_url; I get the HTML page in my browser. But none of the CSS styles are reflected. Also, none of my java-script functions are executed. So not sure what is amiss.
FYI: I noticed the following lines in the log:
[pid: 15730|app: 0|req: 7/7] 127.0.0.1 () {36 vars in 696 bytes} [Thu Apr 25 16:40:50 2013] GET / => generated 11774 bytes in 2 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 8/8] 127.0.0.1 () {36 vars in 710 bytes} [Thu Apr 25 16:40:50 2013] GET /static/jquery/jquery-1.9.1.min.js => generated 2874 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 9/9] 127.0.0.1 () {36 vars in 727 bytes} [Thu Apr 25 16:40:50 2013] GET /static/bootstrap/css/bootstrap.css => generated 2877 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 10/10] 127.0.0.1 () {36 vars in 716 bytes} [Thu Apr 25 16:40:50 2013] GET /static/bootstrap/js/bootstrap.min.js => generated 2883 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 11/11] 127.0.0.1 () {32 vars in 570 bytes} [Thu Apr 25 16:40:50 2013] GET /favicon.ico => generated 2808 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 12/12] 127.0.0.1 () {36 vars in 696 bytes} [Thu Apr 25 16:40:51 2013] GET / => generated 11774 bytes in 2 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 13/13] 127.0.0.1 () {36 vars in 710 bytes} [Thu Apr 25 16:40:51 2013] GET /static/jquery/jquery-1.9.1.min.js => generated 2874 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 14/14] 127.0.0.1 () {36 vars in 727 bytes} [Thu Apr 25 16:40:51 2013] GET /static/bootstrap/css/bootstrap.css => generated 2877 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 15/15] 127.0.0.1 () {36 vars in 716 bytes} [Thu Apr 25 16:40:51 2013] GET /static/bootstrap/js/bootstrap.min.js => generated 2883 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
[pid: 15730|app: 0|req: 16/16] 127.0.0.1 () {32 vars in 570 bytes} [Thu Apr 25 16:40:51 2013] GET /favicon.ico => generated 2808 bytes in 3 msecs (HTTP/1.1 404) 1 headers in 51 bytes (1 switches on core 0)
Is there some additional config that I seem to have missed?
Would greatly appreciate your time and input. I will leave a solution in case I find one.
Best...
You may want to check the section on the django docs about serving static files. The rules for mod_wsgi apply to mod_uwsgi. A more easy approach is configuring uWSGI to serve static files:
http://uwsgi-docs.readthedocs.org/en/latest/StaticFiles.html
Check the part about offloading if your site is pretty loaded
Generally avoid using django for serving static files
I am not using nginx but Apache, running mod_wsgi.
There I have the possibility to use
Alias /static/ /var/www/django-project/static/
All files are in my directory and accesaible at http://example.com/static/.
So maybe you can do the same with nginx.
Edit:
This skips the process of wsgi/cgi/uwsgi and allows the http daemon to handle the static files directly. There is no need for python to parse these kind of requests - because they're only accessing static files.

Nginx connection reset, response from uWsgi lost

I have a django app hosted via Nginx and uWsgi. In a certain very simple request, I get different behaviour for GET and POST, which should not be the case.
The uWsgi daemon log:
[pid: 32454|app: 0|req: 5/17] 127.0.0.1 () {36 vars in 636 bytes} [Tue Oct 19 11:18:36 2010] POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)
[pid: 32455|app: 0|req: 5/18] 127.0.0.1 () {32 vars in 521 bytes} [Tue Oct 19 11:18:50 2010] GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ => generated 80 bytes in 3 msecs (HTTP/1.0 440) 1 headers in 76 bytes (0 async switches on async core 0)
The Nginx accesslog:
127.0.0.1 - - [19/Oct/2010:18:18:36 +0200] "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 0 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"
127.0.0.1 - - [19/Oct/2010:18:18:50 +0200] "GET /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0" 440 80 "-" "curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15"
The Nginx errorlog:
2010/10/19 18:18:36 [error] 4615#0: *5 readv() failed (104: Connection reset by peer) while reading upstream, client: 127.0.0.1, server: localhost, request: "POST /buy/76d4f520ae82e1dfd35564aed64a885b/a_2/10/ HTTP/1.0", upstream: "uwsgi://unix:sock/uwsgi.sock:", host: "localhost:9201"
In essence, Nginx somewhere loses the response if I use POST, not so if I use GET.
Anybody knows something about that?
Pass --post-buffering 1 to uwsgi
This will automatically buffer all the http body > 1 byte
The problem is raised by the way nginx manages upstream disconnections
I hit the same issue, but on my case I can't disable "uwsgi_pass_request_body" as most times (but not always) my app do need the POST data.
This is the workaround I found, while this issue is not fixed in uwsgi:
http://permalink.gmane.org/gmane.comp.python.wsgi.uwsgi.general/813
import django.core.handlers.wsgi
class ForcePostHandler(django.core.handlers.wsgi.WSGIHandler):
"""Workaround for: http://lists.unbit.it/pipermail/uwsgi/2011-February/001395.html
"""
def get_response(self, request):
request.POST # force reading of POST data
return super(ForcePostHandler, self).get_response(request)
application = ForcePostHandler()
I am facing the same issues. I tried all solutions above, but they were not working. Ignoring the response body in my case is simply not an option.
Apparently it is a bug with nginx and uwsgi when dealing with POST requests whose response is smaller than 4052 bytes
What solved it for me was adding "--pep3333-input" to the parameter list of uwsgi. After that all POSTs are returned correctly.
Versions of nginx/uwsgi I'm using:
$ nginx -V
nginx: nginx version: nginx/0.9.6
$ uwsgi --version
uWSGI 0.9.7
After a lucky find in further research (http://answerpot.com/showthread.php?577619-Several%20Bugs/Page2) I found something that helped...
Supplying the uwsgi_pass_request_body off; parameter in the Nginx conf resolves this problem...