Question

您好我有一个django应用程序。我的整个系统配置如下：python 3，django 1.11，eventlet 0.21.0。

1）Nginx作为上游服务器：

upstream proj_server {
        server unix:///tmp/proj1.sock fail_timeout=0;
        server unix:///tmp/proj2.sock fail_timeout=0;
}

2）控制工人的主管。有一个枪手工人：

[program:proj]
command=/home/vagrant/.virtualenvs/proj/bin/gunicorn -c /vagrant/proj/proj/proj/deploy/gunicorn.small.conf.py proj.wsgi:application
directory=/vagrant/proj/proj/proj/deploy
user=www-data
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/proj.log

3）这是 gunicorn.small.conf 内容：

bind = ["unix:///tmp/proj1.sock", "unix:///tmp/proj2.sock"]
pythonpath = "/vagrant/proj/proj/proj/deploy"
workers = 2
worker_class = "eventlet"
worker_connections = 10
timeout = 60
graceful_timeout = 60

4）这是 proj.wsgi 内容：

"""
WSGI config for proj project.

This module contains the WSGI application used by Django's development server
and any production WSGI deployments. It should expose a module-level variable
named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover
this application via the ``WSGI_APPLICATION`` setting.

Usually you will have the standard Django WSGI application here, but it also
might make sense to replace the whole Django WSGI application with a custom one
that later delegates to the Django one. For example, you could introduce WSGI
middleware here, or combine a Django application with an application of another
framework.

"""
import eventlet
eventlet.monkey_patch()
from eventlet import wsgi
import django.core.handlers.wsgi
import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "proj.settings")

# This application object is used by any WSGI server configured to use this
# file. This includes Django's development server, if the WSGI_APPLICATION
# setting points here.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

# Apply WSGI middleware here.
# from helloworld.wsgi import HelloWorldApplication
# application = HelloWorldApplication(application)

所以，你可以看到有一个链：nginx作为上游服务器使用两个套接字 proj1.sock 或 proj2.sock 调用一个gunicorn eventlet worker 。请注意，根据eventlet文档，我尝试尽早使用 eventlet.monkey_patch（）。最合适的地方是 proj.wsgi ，这首先是由gunicorn调用的。

然而，图书馆似乎没有修补。

为了检查这一点，我添加了 proj / proj / proj / __ init __。py （由django应用程序调用的第一个模块）以下代码：

import eventlet
import os
print("monkey patched os is: " + str(eventlet.patcher.is_monkey_patched('os')))
print("monkey patched select is: " + str(eventlet.patcher.is_monkey_patched('select')))
print("monkey patched socket is: " + str(eventlet.patcher.is_monkey_patched('socket')))
print("monkey patched time is: " + str(eventlet.patcher.is_monkey_patched('time')))
print("monkey patched subprocess is: " + str(eventlet.patcher.is_monkey_patched('subprocess')))

then i issued **./manage.py check** and got that answer:

monkey patched os is: false
monkey patched select is: false
monkey patched socket is: false
monkey patched time is: false
monkey patched subprocess is: false

我做错了什么？

Answer 1

如果您将proj.wsgi文件内容更改为一行raise Exception，该怎么办？这应该消除嫌疑人的事件。

我对Django并不擅长，这是一个纯粹的推测：

基于名称，当WSGI服务器即将启动时执行proj.wsgi
manage.py check似乎与远程网络服务（WSGI）无关，似乎是一般管理命令，因此它不应该执行与WSGI相关的代码

一个可能的解决方案，取自您的问题文本：

proj / proj / proj / init .py（由django应用程序调用的第一个模块

尝试将monkey_patch调用放在那里。

P.S。：你不需要主管为gunicorn，它的主过程（仲裁者）设计为尽管工人有问题而永远运行。

Eventlet is_monkey_patched问题False

1 个答案: