uWSGI arbeitet als Prozess, aber nicht als Daemon

Ich gab auf, es wurde kein uwsgi.log generiert und nginx beschwerte sich immer wieder über:

2014/03/06 01:06:28 [error] 23175#0: *22 upstream prematurely closed connection while reading response header from upstream, client: client.IP, server: my.server.IP, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/var/web/the_gelatospot/uwsgi.sock:", Host: "Host.ip"

für jede einzelne Anfrage. Dies geschah nur, wenn uwsgi als Dienst ausgeführt wurde. Als Prozess startete es problemlos unter einem beliebigen Benutzer. Das würde also von der Kommandozeile aus funktionieren (Seite antwortet):

$exec /var/web/the_gelatospot/mez_server.sh

Dies ist nicht gelungen (/etc/init/site_service.conf):

description "mez sites virtualenv and uwsgi_Django" start on runlevel
[2345] stop on runlevel [06] respawn respawn limit 10 5 exec
/var/web/the_gelatospot/mez_server.sh

Der Prozess würde beginnen, aber bei jeder Anfrage würde sich nginx über die geschlossene Verbindung beschweren. Seltsamerweise habe ich die gleiche Konfiguration für 2 andere Apps, die dieselbe Nginx-Version und dieselbe UWSGI-Version verwenden. Beide Apps sind Mezzanine-CMS-Apps. Ich versuchte alles, was mir einfiel und was vorgeschlagen wurde. Am Ende bin ich auf Gunicorn umgestiegen, was gut funktioniert:

#!/bin/bash

NAME="the_gelatospot"                                          # Name of the application
DJANGODIR=/var/web/the_gelatospot              # Django project directory
SOCKFILE=/var/web/the_gelatospot/gunicorn.sock     # we will communicte using this unix socket
USER=ec2-user
GROUP=ec2-user                                             # the user to run as, the group to run as
NUM_WORKERS=3                                     # how many worker processes should Gunicorn spawn
Django_SETTINGS_MODULE=settings
#Django_SETTINGS_MODULE=the_gelatospot.settings             # which settings file should Django use
#Django_WSGI_MODULE=the_gelatospot.wsgi                   # WSGI module name
Django_WSGI_MODULE=wsgi

echo "Starting $NAME as `the_gelatospot`"

# Activate the virtual environment
cd $DJANGODIR
source ../mez_env/bin/activate
export Django_SETTINGS_MODULE=$Django_SETTINGS_MODULE
export PYTHONPATH=$DJANGODIR:$PYTHONPATH

# Create the run directory if it doesn't exist
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR
cd ..
# Start your Django GUnicorn
# Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon)
exec gunicorn -k eventlet ${Django_WSGI_MODULE}:application \
  --name $NAME \
  --workers $NUM_WORKERS \
  --log-level=debug \
  --bind=unix:$SOCKFILE

Und hier ist der, der nicht als Dienst funktionieren würde (Nginx beklagt sich über vorzeitig geschlossene Verbindung und keine App-Protokolldaten, die durchkommen).

#!/bin/bash

DJANGODIR=/var/web/the_gelatospot/                # Django project directory
cd $DJANGODIR
source ../mez_env/bin/activate
uwsgi --ini uwsgi.ini

Und die uwsgi.ini:

[uwsgi]
uid = 222
gid = 500
socket = /var/web/the_gelatospot/uwsgi.sock
virtualenv = /var/web/mez_env
chdir = /var/web/the_gelatospot/
wsgi-file = /var/web/the_gelatospot/wsgi.py
pythonpath = ..
env = Django_SETTINGS_MODULE=the_gelatospot.settings
die-on-term = true
master = true
chmod-socket = 666
;experiment using uwsgitop
worker = 1
;gevent = 100
processes = 1
daemonize = /var/log/nginx/uwsgi.log
logto = /var/log/nginx/uwsgi.logi
log-maxsize = 10000000
enable-threads = true

Ich bin letztes Jahr von Gunicorn zu UWSGI gewechselt und hatte bis jetzt keine Probleme damit, es schien auch ein bisschen schneller zu sein als Gunicorn. Im Moment denke ich daran, mich an Gunicorn zu halten. Es wird besser, bringt viel bessere Zahlen mit installiertem Eventlet und ist einfacher zu konfigurieren.

Hoffe, diese Problemumgehung hilft. Ich würde immer noch gerne das Problem mit uWSGI und Nginx kennen, aber ich bin ratlos.

Update: Die Verwendung von Gunicorn ermöglichte es mir, den Server als Dienst auszuführen, und während ich im Zwischengeschoss spielte, trat der folgende Fehler auf: FileSystemEncodingChanged

Um dies zu beheben, habe ich die Lösung hier gefunden: https://groups.google.com/forum/#!msg/mezzanine-users/bdln_Y99zQw/9HrhNSKFyZsJ

Und ich musste es etwas modifizieren, da ich kein Supervisord verwende, sondern nur Upstart und ein Shell-Skript. Ich habe dies hinzugefügt, bevor ich gunicorn in meiner Datei mez_server.sh ausführe:

export LANG=en_US.UTF-8, LC_ALL=en_US.UTF-8, LC_LANG=en_US.UTF-8
exec gunicorn -k eventlet ${Django_WSGI_MODULE}:application \
  --name $NAME \
  --workers $NUM_WORKERS \
  --log-level=debug \
  --bind=unix:$SOCKFILE

Ich habe dieses Update auch mit uWSGI ausprobiert (viel kürzer als mit uwsgi.ini):

export LANG=en_US.UTF-8, LC_ALL=en_US.UTF-8, LC_LANG=en_US.UTF-8
exec uwsgi --ini uwsgi.ini

Ich halte mich immer noch an Gunicorn, da es immer noch mit dem Problem zusammengearbeitet hat, und führe mich in die richtige Richtung, um es zu lösen. Ich war sehr enttäuscht, dass uWSGI auch mit diesen Parametern keine Ausgabe in der Protokolldatei lieferte. Ich habe nur den Startvorgang des Servers gesehen und das war's:

daemonize = /var/log/nginx/uwsgi.log
logto = /var/log/nginx/uwsgi.logi

Während Nginx den Verbindungsabbruch-Fehler auslöste, saß uWSGI da, als ob nichts passieren würde.