uWSGI-server nicht antwortet

Ich versuche, führen Sie eine Django-Anwendung mit Nginx + uWSGI ohne Erfolg.
Nach stundenlangem googeln und debugging machte ich die einfachste mögliche uwsgi-Konfiguration, die arbeiten müssen:

$ uwsgi --http 127.0.0.1:8000 --wsgi-file test.py

Wo test.py ist

def application(env, start_response):
    start_response('200 OK', [('Content-Type','text/html')])
    return "Hello World"

Das problem ist: es funktioniert nicht. Ein wget-Aufruf auf dem gleichen Rechner hängt:

$ wget http://127.0.0.1:8000
--2013-04-28 12:43:36--  http://127.0.0.1:8000/
Connecting to 127.0.0.1:8000... connected.
HTTP request sent, awaiting response...

uWSGI-Ausgang ist stummgeschaltet (außer für erste Informationen):

*** Starting uWSGI 1.9.8 (32bit) on [Sun Apr 28 12:43:56 2013] ***
compiled with version: 4.4.5 on 28 April 2013 06:22:28
os: Linux-2.6.27-ovz-4 #1 SMP Mon Apr 27 00:26:17 MSD 2009
...

Die Verbindung ist in der Tat, denn das töten von uWSGI bricht wget.

Wahrscheinlich uWSGI ist nicht detailliert genug über die aufgetretenen Fehler, oder muss ich was verpasst habe.
Jeden Tipp, wo weiter zu suchen ist geschätzt.

Update:

Weitere system-details: Debian 6.0.7, Python-2.6.6.

Einer vollständigen uWSGI log auf der Startseite:

$ uwsgi --http 127.0.0.1:8000 --wsgi-file test.py
*** Starting uWSGI 1.9.8 (32bit) on [Mon Apr 29 04:50:03 2013] ***
compiled with version: 4.4.5 on 28 April 2013 06:22:28
os: Linux-2.6.27-ovz-4 #1 SMP Mon Apr 27 00:26:17 MSD 2009
nodename: max.local
machine: i686
clock source: unix
detected number of CPU cores: 4
current working directory: /home/user/dir
detected binary path: /home/user/dir/env/ENV/bin/uwsgi
*** WARNING: you are running uWSGI without its master process manager ***
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
uWSGI http bound on 127.0.0.1:8000 fd 4
spawned uWSGI http 1 (pid: 19523)
uwsgi socket 0 bound to TCP address 127.0.0.1:57919 (port auto-assigned) fd 3
Python version: 2.6.6 (r266:84292, Dec 27 2010, 00:18:12)  [GCC 4.4.5]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x80f6240
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 63944 bytes (62 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x80f6240 pid: 19522 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 19522, cores: 1)

Und sonst nichts ist jemals gedruckt wurden.

Bitte melden Sie die vollständigen uWSGI startup Protokolle, das Beispiel, das Sie berichtet, überall zu arbeiten (es sei denn, Sie sind mit Python ist3, erfordert eine andere Rendite-Objekt), aber vielleicht gibt es einige andere Probleme. Von dem, was Sie beschreiben, es sieht aus wie eine Art firewall auf Ihrem system, aber es wäre seltsam, auf 127.0.0.1...

InformationsquelleAutor Maxim | 2013-04-28

2

Für diejenigen, die möglicherweise dieses problem auftreten, auch hier sind die endgültigen Ergebnisse meiner Untersuchung:
das Problem ist definitiv, Fragen der Umwelt, und die meisten wahrscheinlich Linux-kernel-spezifisch.
Die strace util zeigten, dass uWSGI konnte nicht ein einzelnes byte ist - es ist ein kernel-Ebene.

Ich denke, key line ist
```
os: Linux-2.6.27-ovz-4
```
Das Linux läuft in einer virtuellen Umgebung und 2.6.27 ist nicht ein Standard-kernel-version für Debian 6.0.7. In 2.6.32-5 funktionierte alles perfekt.

Ich weiß nicht, ob es ein Fehler ist von einem alten kernel, oder uWSGI Verträglichkeit, oder beides. Aber die Aktualisierung der kernel hilft.

InformationsquelleAutor Maxim
1

Ich hatte das gleiche problem mit der exakt gleichen Symptome, nachdem ich das installiert uwsgi mit pip.

Ich löste das problem durch eine Neuinstallation uwsgi aus dem tarball, d.h. nach der docs mit
```
wget http://projects.unbit.it/downloads/uwsgi-latest.tar.gz
tar zxvf uwsgi-latest.tar.gz
cd <dir>
make
```
Daraus wurden ein uwsgi binäre, dass, wenn verwendet, um den docs Beispiel, das Sie erwähnen, ein Protokoll gedruckt, die unterschieden sich nur in das Protokoll der pip-basierte version uwsgi in der python-version verwendet -- lauffähige version war die gleiche (uWSGI 2.0.13.1, 64bit). Die tarball-version verwendet Python 2.7.6, während die pip-basierte version verwendet Python 3.4.3 . Die installierte version als der default, also die version, wo die /usr/bin/python symbolische link zeigt, war Python 2.7.6 auf meinem system.

Es stellt sich heraus, dass dieser ja gar nicht, ein Zufall, wie die änderung vorübergehend die /usr/bin/python link zu Python 3.4.3 (und die änderung der Rendite-Objekt in test.py für Python 3), die die pip-basierte ausführbare Arbeit.

Die Quintessenz ist, dass Sie sollten überprüfen Sie, dass die Python-version im uwsgi log deckt sich mit der Standard-version von Ihrem system. Ich bin mir nicht was darauf hindeutet, dass die Installation aus dem tarball ist besser als die Installation von pip hier; ich vermute, dass es Zufall war, dass die eine Quelle hatte die richtige Python-version, während der andere nicht. Also eine Möglichkeit, dieses problem zu lösen, ist versuchen einen anderen Weg zu installieren uwsgi.

InformationsquelleAutor Giorgos Sfikas
0

Ich habe nie geschrieben, ein bare-bones-WSGI-Anwendung, aber mit Blick auf verschiedene tutorials es scheint, dass Sie zurückkehren sollte, eine Liste oder einen generator: entweder
```
return ['Hello world']
```
oder
```
yield 'Hello world'
```
Ich nahm das Beispiel von doc, so sollte es funktionieren. Im schlimmsten Fall würde es haben, führte Ausnahme.

InformationsquelleAutor Daniel Roseman

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.