gunicorn配置是由一个不再由我们支配的人完成的,而且我真的不知道枪炮,我无法修复甚至找不到问题,所以我恢复到版本18.0并且它现在正在工作.但是,我想最终升级它并将配置放在可以工作的形状中.我有一种感觉,当前的配置是次优或多余的,但我无法确定:-).
在环境中没有任何改变(或者是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.没有记录任何内容.事实上,在日志文件变得惊人的大小之后,看起来我的前任禁用了gunicorn记录了一段时间,但这是另一天的问题.
以下是相关文件的内容：
/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")
解决方法
原来这是配置文件中有问题的行：
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,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升级.
gunicorn的文档似乎有问题,我打算报告,因为在撰写本文时,the docs for v19.2.1仍然声明egg：gunicorn#[worker]语法是有效的. (这里的例子使用了gevent,但它看起来应该适用于其他类型).谁知道,它可能在某些情况下是有效的,但在我的(带有pip的virtualenv中的gunicorn),它不是.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。