Question

我正在尝试使用Nginx + uWSGI运行Django应用程序但没有成功。经过数小时的谷歌搜索和调试，我做了最简单的uwsgi配置，必须工作：

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

test.py在哪里

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

问题是：它没有。同一台机器上的wget调用挂起：

$ 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输出是静默的（初始信息除外）：

*** 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
...

事实上已建立连接，因为杀死uWSGI会中止wget。

可能uWSGI对发生的错误不够详细，或者我一定错过了什么。任何进一步观察的提示都表示赞赏。

更新

更多系统细节：Debian 6.0.7，Python 2.6.6。

完整的uWSGI登录开始：

$ 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)

没有别的东西打印出来。

Answer 1

对于那些可能遇到此问题的人来说，这是我调查的最终结果：问题肯定与环境有关，而且很可能是Linux内核特有的。 strace util显示uWSGI无法接收单个字节 - 它是内核级别。

我认为关键行是

os: Linux-2.6.27-ovz-4

Linux在虚拟环境中运行，2.6.27不是Debian 6.0.7的默认内核版本。在2.6.32-5中，一切都很完美。

我不知道它是旧内核的错误，还是uWSGI兼容性，或两者兼而有之。但更新内核会有所帮助。

Answer 2

在使用pip安装uwsgi之后，我遇到了完全相同症状的问题。

我通过从tarball重新安装uwsgi解决了这个问题，即根据docs和

wget http://projects.unbit.it/downloads/uwsgi-latest.tar.gz
tar zxvf uwsgi-latest.tar.gz
cd <dir>
make

这导致了一个uwsgi二进制文件，当用于运行文档示例时，你提到打印的日志只与使用的python版本中基于pip的版本uwsgi的日志不同 - 可执行版本是相同的{{ 1}}。基于tarball的版本使用Python 2.7.6，而基于pip的版本使用Python 3.4.3。作为默认安装的版本，即(uWSGI 2.0.13.1, 64bit)符号链接指向的版本，是我系统上的Python 2.7.6。

事实证明，这根本不是巧合，因为临时更改了{3.4}的/usr/bin/python链接（以及更改Python 3中/usr/bin/python的返回对象），使基于pip的可执行文件工作。

最重要的是，您应该检查uwsgi日志中的Python版本是否与系统的默认版本一致。我并不是说从tarball安装比从pip安装更好;我的猜测是巧合的是，一个来源有正确的Python版本，而另一个没有。因此，解决此问题的一种方法是尝试另一种方法来安装uwsgi 。

Answer 3

我从来没有编写过一个简单的WSGI应用程序，但是看看各种教程似乎应该返回一个列表或生成器：

return ['Hello world']

或

yield 'Hello world'

uWSGI服务器没有响应

更新

3 个答案: