gunicorn 19.2未能以18.0configuration启动

我有一个dev服务器在nginx后面运行gunicorn / Django。 作为更广泛的服务器环境更新的一部分,我试图将gunicorn从18.0升级到19.2.1,但服务将不再启动。 (服务器正在运行Arch,因此使用systemctl。)

gunicorn的configuration是由一个已经不在我们手中的人来完成的,并且不是真的知道gunicorn那么好,我无法修复,甚至找不到这个问题,所以我回到了18.0版本,现在它已经在运行了。 不过,我想最终升级它,并将其configuration成可以工作的形状。 我有一种感觉,目前的configuration是不是最理想的或多余的,但我无法肯定知道:-)。

在环境中没有任何变化(或者是运行在gunicorn的virtualenv),只有gunicorn本身被升级。 Systemctl在systemctl start gunicorn上产生这个错误:

 ● gunicorn.service - gunicorn daemon (production) Loaded: loaded (/usr/lib/systemd/system/gunicorn.service; enabled) Active: failed (Result: resources) since Tue 2015-02-17 20:55:41 UTC; 8s ago Process: 2837 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCESS) Process: 9608 ExecReload=/bin/kill -s HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 5353 ExecStart=/home/django/gunicorn/run.sh (code=exited, status=0/SUCCESS) Main PID: 24876 (code=exited, status=0/SUCCESS) Feb 17 20:55:41 ashima systemd[1]: PID file /home/django/gunicorn/gunicorn.pid not readable (yet?) after start. Feb 17 20:55:41 ashima systemd[1]: gunicorn.service never wrote its PID file. Failing. Feb 17 20:55:41 ashima systemd[1]: Failed to start gunicorn daemon (production). Feb 17 20:55:41 ashima systemd[1]: Unit gunicorn.service entered failed state. 

试图从shell中手动运行包含在run.sh的gunicorn命令(粘贴在下面),它立即退出而不会产生任何错误,退出代码为0.没有logging任何内容。 事实上,在日志文件增长到一个惊人的大小之后,看起来我的前任禁用了gunicorn日志logging,但这是另一个问题。

这里是相关文件的内容:

/usr/lib/systemd/system/gunicorn.service:

 [Unit] Description=gunicorn daemon [Service] Type=forking PIDFile=/home/django/gunicorn/gunicorn.pid User=django WorkingDirectory=/home/django/[name_withheld]/project ExecStart=/home/django/gunicorn/run.sh ExecReload=/bin/kill -s HUP $MAINPID ExecStop=/bin/kill -s QUIT $MAINPID PrivateTmp=false [Install] WantedBy=multi-user.target 

/home/django/gunicorn/run.sh:

 #!/bin/bash set -e cd /home/django/[name_withheld]/project source /home/django/.venv/bin/activate exec gunicorn -p /home/django/gunicorn/gunicorn.pid -c /home/django/gunicorn/config.py -e HTTPS=on [name_withheld]_site.wsgi:application 

/home/django/gunicorn/config.py:

 bind = 'unix:/tmp/gunicorn.sock' backlog = 2048 workers = 16 worker_class = 'egg:gunicorn#sync' worker_connections = 1000 timeout = 30 keepalive = 2 debug = False spew = False daemon = True pidfile = None umask = 0755 user = None group = None tmp_upload_dir = None raw_env = 'HTTPS=on' errorlog = '-' loglevel = 'info' accesslog = None proc_name = None def post_fork(server, worker): server.log.info("Worker spawned (pid: %s)", worker.pid) def pre_fork(server, worker): pass def pre_exec(server): server.log.info("Forked child, re-executing.") def when_ready(server): server.log.info("Server is ready. Spawning workers") 

(在这个问题上发表的意见中,我必须特别用skarap来expression这个意见 ,因为它帮助我find了一个解决scheme,让gunicorn正确地输出错误,我希望我能给予一个部分的奖励,转换那个评论的答案还不是一个完整的答案,但是确实有帮助。)

原来这是configuration文件中有问题的行:

worker_class = 'egg:gunicorn#sync'

它造成了这个错误:

 Error: class uri 'egg:gunicorn#sync' invalid or not found: [Traceback (most recent call last): File "/home/django/.venv/lib/python2.7/site-packages/gunicorn/util.py", line 113, in load_class return pkg_resources.load_entry_point(dist, section, name) File "/home/django/.venv/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 318, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/home/django/.venv/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 2220, in load_entry_point raise ImportError("Entry point %r not found" % ((group,name),)) ImportError: Entry point ('gunicorn.workers', 'sync') not found ] 

worker_class = 'sync'代替它解决了ImportError,因此也解决了这个问题。 在18.0 – > 19.2.1升级中,没有其他configuration需要更改。

我打算报告gunicorn的文档似乎存在一个问题,因为在撰写本文时, v19.2.1的文档仍然声明egg:gunicorn#[worker]语法是有效的。 (这里的例子使用gevent,但它看起来应该适用于其他types)。 谁知道,这在某些情况下可能是有效的,但是在我的(在virtualenv的gunicorn,用pip安装),它不是。