uWSGI serveur ne répond pas
Je suis en train de lancer une application Django aide de Nginx + uWSGI, sans succès.
Après des heures de recherche sur google et le débogage j'ai fait le plus simple possible uwsgi de configuration qui doivent travailler:
$ uwsgi --http 127.0.0.1:8000 --wsgi-file test.py
Où test.py est
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return "Hello World"
Le problème: il n'a pas. Un wget appel sur la même machine se bloque:
$ 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 de sortie est silencieux (sauf pour les premières informations):
*** 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
...
La connexion est établi, en effet, parce que tuer uWSGI abandonne wget.
Probablement uWSGI n'est pas assez détaillé à propos de survenue des erreurs, ou dois-je l'ai raté quelque chose.
Toute la pointe de l'endroit où chercher plus loin est apprécié.
Mise à jour:
Plus de détails sur le système: Debian 6.0.7, Python 2.6.6.
Plein uWSGI journal sur start:
$ 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)
Et rien d'autre n'est jamais imprimé.
- Veuillez signaler les uWSGI de démarrage des journaux, l'exemple que vous avez signalé devrait fonctionner partout (sauf si vous utilisez python3 qui nécessite un autre objet de retour), mais peut-être il ya un autre problème. À partir de ce que vous décrivez, il ressemble à une sorte de pare-feu est activé sur votre système, mais il serait étrange sur 127.0.0.1...
Vous devez vous connecter pour publier un commentaire.
Pour ceux qui rencontre ce problème aussi ici êtes final les résultats de mon enquête:
la question est certainement liée à l'environnement, et plus probablement noyau Linux spécifique.
Le strace util a montré que uWSGI ne pouvait pas recevoir un seul octet - c'est un niveau du noyau.
Je pense que la clé de la ligne est
Linux est en cours d'exécution dans un environnement virtuel et 2.6.27 n'est pas un défaut de la version de noyau de Debian 6.0.7. En 2.6.32-5 tout a fonctionné parfaitement.
Je ne sais pas si c'est un bug d'un vieux noyau, ou uWSGI de compatibilité, ou les deux. Mais la mise à jour du noyau aide.
J'ai eu le même problème avec exactement les mêmes symptômes, après avoir installé uwsgi avec
pip
.J'ai résolu le problème en réinstallant uwsgi à partir de l'archive, c'est à dire selon la docs avec
Cela se traduit par une uwsgi binaire, que lorsqu'il est utilisé pour exécuter les docs exemple que vous mentionnez imprimé un journal qui ne se distinguait dans le journal de la pip version uwsgi dans la version de python utilisée -- version exécutable a été la même
(uWSGI 2.0.13.1, 64bit)
. L'archive version utilisé Python 2.7.6, tandis que le pip-en fonction de la version utilisée Python 3.4.3 . La version installé en tant que par défaut, c'est à dire la version où le/usr/bin/python
lien symbolique pointe, a été Python 2.7.6 sur mon système.Il s'avère que ce n'était pas une coïncidence, que de changer temporairement la
/usr/bin/python
lien vers Python 3.4.3 (et une modification de l'objet de retour danstest.py
pour Python 3), faite le pip base de travail exécutable.La ligne de fond est que vous devriez vérifier que la version de Python à la uwsgi journal coïncide avec la version par défaut de votre système. Je ne dis pas que l'installation de l'archive est mieux que d'installer de pip ici; je pense que c'était une coïncidence que la source avait la bonne version de Python, tandis que l'autre n'a pas. Donc une façon de résoudre ce problème est de essayer une autre façon d'installer uwsgi.
Je n'ai jamais écrit un bare-bones application WSGI, mais en regardant les différents tutoriels il semble que vous devez retourner une liste ou d'un générateur: soit
ou