1

我正在尝试使用 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)

没有其他任何东西被打印出来。

4

3 回答 3

2

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

我认为关键线是

os: Linux-2.6.27-ovz-4

Linux 在虚拟环境中运行，并且 2.6.27 不是 Debian 6.0.7 的默认内核版本。在 2.6.32-5 中，一切正常。

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

于 2013-05-02T15:23:52.787 回答
1

I had the same problem with the exact same symptoms, after having installed uwsgi with pip.

I solved the problem by reinstalling uwsgi from the tarball, i.e. according to the docs with

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

This resulted into a uwsgi binary, that when used to run the docs example you mention printed a log that only differed to the log of the pip-based version uwsgi in the python version used -- executable version was the same (uWSGI 2.0.13.1, 64bit). The tarball-based version used Python 2.7.6, while the pip-based version used Python 3.4.3 . The version installed as the default, i.e. the version where the /usr/bin/python symbolic link points to, was Python 2.7.6 on my system.

It turns out that this wasn't at all a coincidence, as changing temporarily the /usr/bin/python link to Python 3.4.3 (and changing the return object in test.py for Python 3), made the pip-based executable work.

The bottom line is that you should check that the Python version at the uwsgi log coincides with the default version of your system. I'm not suggesting that installing from the tarball is better than installing from pip here; my guess that it was coincidental that the one source had the correct Python version while the other didn't. So one way to solve this problem is to try another way to install uwsgi.

于 2016-07-07T14:36:30.857 回答
-1

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

return ['Hello world']

或者

yield 'Hello world'
于 2013-04-28T18:34:50.913 回答