Nginx Django和Gunicorn。缺少Gunicorn sock文件？

Question

我有一个基于这个https://github.com/jcalazan/ansible-django-stack的ansible配置的VM，但是由于某些原因，尝试启动Gunicorn会导致以下错误：

Can't connect to /path/to/my/gunicorn.sock

在nginx日志文件中：

connect() to unix:/path/to/my/gunicorn.sock failed (2: No such file or directory) while connecting to upstream

实际上，指定目录中缺少套接字文件。我已经检查了目录的权限，它们很好。

这是我的gunicornúu开始脚本：

NAME="{{ application_name }}"
DJANGODIR={{ application_path }}
SOCKFILE={{ virtualenv_path }}/run/gunicorn.sock
USER={{ gunicorn_user }}
GROUP={{ gunicorn_group }}
NUM_WORKERS={{ gunicorn_num_workers }}

# Set this to 0 for unlimited requests. During development, you might want to
# set this to 1 to automatically restart the process on each request (i.e. your
# code will be reloaded on every request).
MAX_REQUESTS={{ gunicorn_max_requests }}

echo "Starting $NAME as `whoami`"

# Activate the virtual environment.
cd $DJANGODIR
. ../../bin/activate

# Set additional environment variables.
. ../../bin/postactivate

# Create the run directory if it doesn't exist.
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR

# Programs meant to be run under supervisor should not daemonize themselves
# (do not use --daemon).
exec gunicorn \
    --name $NAME \
    --workers $NUM_WORKERS \
    --max-requests $MAX_REQUESTS \
    --user $USER --group $GROUP \
    --log-level debug \
    --bind unix:$SOCKFILE \
    {{ application_name }}.wsgi

有人能告诉我还有什么可能导致丢失的套接字文件吗？

谢谢

Answer 1

我也遇到了同样的问题，发现我在gunicorn脚本中将DJANGO_SETTINGS_模块设置为生产设置，而wsgi设置使用dev

我把DJANGO_SETTINGS_模块指向dev，一切正常。

Answer 2

在跟随Michal Karzynski的伟大指南Setting up Django with Nginx, Gunicorn, virtualenv, supervisor and PostgreSQL之后，我遇到了同样的问题。

我就是这样解决的。

bash脚本中有一个变量，用于通过Supervisor（myapp/bin/gunicorn_start）启动gunicorn：

SOCKFILE={{ myapp absolute path }}/run/gunicorn.sock

当您第一次运行bash脚本时，它会使用根特权创建一个“run”文件夹和一个sock文件。所以我sudo删除了run文件夹，然后重新创建了它，没有sudo权限和voila！现在，如果您重新运行Gunicorn或Supervisor，您将不再有恼人的丢失sock文件错误消息！

TL；DR

1. Sudo删除运行文件夹。
2. 在没有sudo权限的情况下重新创建它。
3. 再次运行Gunicorn。
4. ？？？？
5. 利润

Answer 3

好吧，因为我没有足够的代表来评论，我在这里要提到的是，这个缺失的插座并没有暗示出太多的特殊性，但是我可以告诉你一些我是如何从你的角度出发，让事情顺利进行的。

长短不一的是，gunicorn在被新贵经营时遇到了一个问题，要么从未起来经营，要么就停产了。以下是一些步骤，可以帮助您获取更多信息以跟踪您的问题：

• 在我的例子中，当发生这种情况时，gunicorn从来没有做过任何错误日志记录，所以我不得不寻找其他地方。试着ps auxf | grep gunicorn看看你有没有工人要去。我没有
• 在系统日志中查找来自upstart的投诉，grep init: /var/log/syslog，显示我的gunicorn服务已经停止，因为它重生太快了，尽管我怀疑这会是您的问题，因为您的配置中没有重生。无论如何，您可能会在那里找到一些东西。

• 在看到gunicorn无法运行或记录错误后，我决定尝试从命令行运行它。转到manage.py所在的目录，对gunicorn实例运行upstart命令的扩展版本。比如（用适当的垃圾代替我使用的垃圾）

  /path/to/your/virtualenv/bin/gunicorn --name myapp --workers 4 --max-requests 10 --user appuser --group webusers --log-level debug --error-logfile /somewhere/I/can/find/error.log --bind unix:/tmp/myapp.socket myapp.wsgi

• 如果幸运的话，在手动运行该命令之后，您可能会得到一个python回溯，或者在gunicorn错误日志中找到一些内容。有些事情可能会出错：

  • django错误（加载设置模块时可能出现问题？）。确保wsgi.py引用的是服务器上相应的设置模块。
  • 新贵脚本中的空白问题。我有一个标签藏在那些把东西塞满的地方。
  • 用户/权限问题。最后，我可以在命令行上以根用户的身份运行gunicorn，但不能通过upstart配置以非根用户的身份运行。

希望能有所帮助。追踪这些东西已经有好几天了。