uWSGI 服务器没有响应

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 工具显示 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 with

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

这导致了一个 uwsgi 二进制文件，当用于运行您提到的文档示例时，它打印了一个日志，该日志仅与所使用的 python 版本中基于 pip 的版本 uwsgi 的日志不同——可执行版本相同 @987654324 @。基于 tarball 的版本使用 Python 2.7.6，而基于 pip 的版本使用 Python 3.4.3。默认安装的版本，即/usr/bin/python符号链接指向的版本，是我系统上的Python 2.7.6。

事实证明，这根本不是巧合，因为临时将 /usr/bin/python 链接更改为 Python 3.4.3（并更改了 Python 3 的 test.py 中的返回对象），使得基于 pip 的可执行文件工作。

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

Answer 3

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

return ['Hello world']

或

yield 'Hello world'