Interner Serverfehler mit Django und uWSGI 2 Emperor-Modus

Question

Ich habe versucht, alles zu lesen, was ich zu diesem Thema finden kann (und dabei viel gelernt habe). Der nächste Link, den ich finden konnte, ist here und here. Mein Problem ist fast identisch, außer dass ich uwsgi ausschließlich im Kaiser-Modus laufen lasse. Wenn ich uwsgis services laufe, OHNE im Kaisermodus zu laufen, läuft meine django-Website gut. Egal, wie ich meine Konfiguration ändere, bekomme ich immer die Fehlermeldung meine /tmp/uwsgi.log Datei: "--- keine Python-Anwendung gefunden, überprüfen Sie Ihre Start-Protokolle für Fehler ---" Ich habe meine Konfiguration und Fehlerprotokoll unten aufgeführt :

OS Version: Linux Raspberry Pi 3.6.11+ # 538 armv6l GNU/Linux
Django Version: 1.6.5
uwsgi Version: 2.0.5.1

Virtuelle Umgebung:/var/www/Testbed/env
Projektort: ​​/ var/www/testbed/project/auth
Projektbaum:

./auth/ 
|-- __init__.py 
|-- __init__.pyc 
|-- requirements.txt 
|-- settings.py 
|-- settings.pyc 
|-- urls.py 
|-- urls.pyc 
|-- wsgi.py 
`-- wsgi.pyc 

Datei wsgi.py:

""" 
WSGI config for auth project. 

It exposes the WSGI callable as a module-level variable named ``application``. 

For more information on this file, see 
https://docs.djangoproject.com/en/1.6/howto/deployment/wsgi/ 
""" 

    import os, sys, site 

    sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "../../"))) 
    sys.path.insert(1, os.path.abspath(os.path.join(os.path.dirname(__file__), "../"))) 
    sys.path.append('/usr/lib/python2.7') 
    sys.path.append('/usr/lib/python2.7/dist-packages') 

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "auth.settings") 

    from django.core.wsgi import get_wsgi_application 
    application = get_wsgi_application() 

Datei /etc/uwsgi/emperor.ini:

[uwsgi] 
master = true 
emperor = /etc/uwsgi/vassals 
logto = /tmp/uwsgi.log 

Datei /etc/uwsgi/vessals/auth.ini:

[uwsgi] 
#plugins = python 
# Django-related settings 
chdir   =/var/www/testbed/project/auth 
module   = auth.wsgi:application 

# the virtualenv (full path) 
home   =/var/www/testbed/env 
virtualenv  =/var/www/testbed/env 

# process-related settings 
enable-threads = true 
pythonpath  = /var/www/testbed/project/auth 
#wsgi-file  = /var/www/testbed/project/auth/auth/wsgi.py 
env    = DJANGO_SETTINGS_MODULE=auth.settings 

mount = /testbed/auth/admin=/var/www/testbed/project/auth/auth/wsgi.py 
manage-script-name = true 
#route-run = log:SCRIPT_NAME=${SCRIPT_NAME} 

# maximum number of worker processes 
processes  = 1 #Simple rule is # of cores on machine 
# the socket (use the full path to be safe 
socket   = /var/www/testbed/project/auth/uwsgi.sock 
# ... with appropriate permissions - may be needed 
chmod-socket = 664 
# clear environment on exit 
vacuum   = true 
logto   = /tmp/uwsgi.log 

Der Befehl, der ausgeführt wird, ist unten aufgeführt:

/var/www/testbed/env/bin/uwsgi --ini /etc/uwsgi/emperor.ini --emperor /etc/uwsgi/vassals/ --http :8000 --plugin python --binary-pathusr/local/bin/uwsgi 

Fehlerdatei /tmp/uwsgi.log:

*** Starting uWSGI 2.0.5.1 (32bit) on [Tue Jun 10 19:06:12 2014] *** 
compiled with version: 4.6.3 on 10 June 2014 01:41:52 
os: Linux-3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 
nodename: raspberrypi 
machine: armv6l 
clock source: unix 
detected number of CPU cores: 1 
current working directory: /etc/uwsgi 
detected binary path: /usr/local/bin/uwsgi 
!!! no internal routing support, rebuild with pcre support !!! 
uWSGI running as root, you can use --uid/--gid/--chroot options 
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 
your processes number limit is 3376 
your memory page size is 4096 bytes 
detected max file descriptor number: 1024 
lock engine: pthread robust mutexes 
thunder lock: disabled (you can enable it with --thunder-lock) 
uWSGI http bound on :8000 fd 6 
*** starting uWSGI Emperor *** 
uwsgi socket 0 bound to TCP address 127.0.0.1:57524 (port auto-assigned) fd 5 
Python version: 2.7.3 (default, Mar 18 2014, 05:13:23) [GCC 4.6.3] 
*** has_emperor mode detected (fd: 8) *** 
[uWSGI] getting INI configuration from auth.ini 
*** Starting uWSGI 2.0.5.1 (32bit) on [Tue Jun 10 19:06:12 2014] *** 
compiled with version: 4.6.3 on 09 June 2014 23:07:00 
os: Linux-3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 
nodename: raspberrypi 
machine: armv6l 
clock source: unix 
detected number of CPU cores: 1 
current working directory: /etc/uwsgi/vassals 
detected binary path: /usr/local/bin/uwsgi 
!!! no internal routing support, rebuild with pcre support !!! 
uWSGI running as root, you can use --uid/--gid/--chroot options 
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 
your processes number limit is 3376 
your memory page size is 4096 bytes 
detected max file descriptor number: 1024 
lock engine: pthread robust mutexes 
thunder lock: disabled (you can enable it with --thunder-lock) 
uwsgi socket 0 bound to UNIX address /var/www/testbed/project/auth/uwsgi.sock fd 3 
Python version: 2.7.3 (default, Mar 18 2014, 05:13:23) [GCC 4.6.3] 
Set PythonHome to /var/www/testbed/env 
*** Python threads support is disabled. You can enable it with --enable-threads *** 
Python main interpreter initialized at 0x1dca830 
your server socket listen backlog is limited to 100 connections 
your mercy for graceful operations on workers is 60 seconds 
mapped 128512 bytes (125 KB) for 1 cores 
*** Operational MODE: single process *** 
*** no app loaded. going in full dynamic mode *** 
*** uWSGI is running in multiple interpreter mode *** 
spawned uWSGI master process (pid: 23068) 
spawned uWSGI worker 1 (pid: 23071, cores: 1) 
spawned uWSGI http 1 (pid: 23072) 
Python main interpreter initialized at 0x616918 
python threads support enabled 
your server socket listen backlog is limited to 100 connections 
your mercy for graceful operations on workers is 60 seconds 
mapped 128512 bytes (125 KB) for 1 cores 
*** Operational MODE: single process *** 
added /var/www/testbed/project/auth/ to pythonpath. 
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x616918 pid: 23070 (default app) 
mounting /var/www/testbed/project/auth/auth/wsgi.py on /testbed/auth/admin 
added /var/www/testbed/project/auth/ to pythonpath. 
WSGI app 1 (mountpoint='/testbed/auth/admin') ready in 3 seconds on interpreter 0x9c6218 pid: 23070 
*** uWSGI is running in multiple interpreter mode *** 
spawned uWSGI master process (pid: 23070) 
Tue Jun 10 19:06:18 2014 - [emperor] vassal auth.ini has been spawned 
spawned uWSGI worker 1 (pid: 23073, cores: 1) 
Tue Jun 10 19:06:18 2014 - [emperor] vassal auth.ini is ready to accept requests 
--- no python application found, check your startup logs for errors --- 
[pid: 23071|app: -1|req: -1/1] 192.168.1.6() {38 vars in 742 bytes} [Tue Jun 10 19:07:11 2014] GET /testbed/auth/admin => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0) 
--- no python application found, check your startup logs for errors --- 
[pid: 23071|app: -1|req: -1/2] 192.168.1.6() {36 vars in 626 bytes} [Tue Jun 10 19:07:11 2014] GET /favicon.ico => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0) 
--- no python application found, check your startup logs for errors --- 
[pid: 23071|app: -1|req: -1/3] 192.168.1.6() {38 vars in 742 bytes} [Tue Jun 10 19:07:13 2014] GET /testbed/auth/admin => generated 21 bytes in 2 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0) 
--- no python application found, check your startup logs for errors --- 
[pid: 23071|app: -1|req: -1/4] 192.168.1.6() {36 vars in 626 bytes} [Tue Jun 10 19:07:13 2014] GET /favicon.ico => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0) 

An diesem Punkt bin ich dem Strohhalm greifen. Von all dem Lesen, das ich gemacht habe, kann ich nicht sehen, warum das den "Internal Server Error" weitergibt. Ich habe vielleicht etwas übersehen, warum ich meinem Stolz endlich nachgegeben habe, indem ich hier meine Sorgen gepostet habe. Da ich so weit gekommen bin, denke ich wirklich, dass ich etwas sehr Kleines übersehen habe. Jede Hilfe würde sehr geschätzt werden.

Answer 1

hatte ich dieses Problem mehrmals in meinen Installationen mit USGI-Kaiser ein Problem war, dass ich nicht die richtigen allowed_hosts in meinem Django-Projekt-Konfigurationsdatei

In der Config festgelegt haben shold Sie haben

ALLOWED_HOSTS=[ "yourdomain.com", "other.domain.com" ] 

oder diese (wegen Sicherheitsbedenken entmutigt, verwenden Sie auf eigene Gefahr):

ALLOWED_HOSTS=["*"] 

zu jedem Host erlauben

https://docs.djangoproject.com/en/1.8/ref/settings/#allowed-hosts