Вопрос: gunicorn 19.2 не запускается с конфигурацией 18,0


У меня есть dev-сервер, запускающий gunicorn / Django за nginx. В рамках более широкого обновления серверной среды я попытался обновить gunicorn с 18.0 до 19.2.1, но служба больше не будет запускаться. (Сервер работает с Arch и поэтому использует systemctl.)

Конфигурация пушки была сделана кем-то, кто больше не находится в нашем распоряжении, и на самом деле не зная, что это был пулемет, я не смог исправить или даже найти проблему, поэтому вернулся к версии 18.0 и теперь работает. Тем не менее, я хотел бы в конечном итоге обновить его и получить конфигурацию в форме, где она будет работать. У меня такое ощущение, что текущая конфигурация является субоптимальной или избыточной, но я не знаю наверняка :-).

Ничто не изменилось в окружающей среде (или на виртуальном уровне, в котором запущен пулемет), был модернизирован только сам артиллерист. 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.

Пытаясь запустить команду пушки, содержащуюся в run.sh (вставляемый ниже) вручную из оболочки, он просто выходил немедленно, не создавая ошибок, с кодом выхода 0. Ничего не было зарегистрировано. На самом деле, похоже, что мой предшественник отключил ведение канониров в течение некоторого времени после того, как файл журнала вырос до тревожного размера, но это проблема еще на один день.

Вот содержание соответствующих файлов:

/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")

5
2018-02-17 21:40


Источник


Попробуйте запустить скрипт с помощью 'strace -f' и посмотреть, показывает ли это какие-либо ошибки (будьте предупреждены, будет много результатов, и большая часть из них будет тарабарщиной для непосвященных!). Вы можете вставить его в пастебин где-нибудь и сообщить нам об этом. - Tim Stoop
Возможно, ошибка systemd может помочь вам приступить к настройке проблем, т. Е. по арктике: wiki.archlinux.org/index.php/... - Dennis Nolte
После Active: failed (Result: resources) остальное - это просто удачная очистка. Проверьте вывод журнала systemd, как и последние 10 событий с journalctl --lines=10 - Brian
Быстрое обновление: попробовав представленные предложения, вероятно, потребуется немного времени простоя на сервере, я постараюсь организовать его как можно скорее. - JK Laiho
Когда вы выполняете /home/django/gunicorn/run.sh вручную, запускается сервис (вы должны увидеть 17 экземпляров пушки, работающих в ps aux). Если это не сработает, избавитесь от debug = False, errorlog = '-' а также daemon = True строки в config, и вставьте здесь ошибку. После того, как он будет работать вручную, службе systemd также потребуется исправление. - skarap


Ответы:


(Из комментариев, отправленных на вопрос, я должен особо skarap, так как это помогло мне найти решение самостоятельно, сделав пулеметы надлежащим образом выводя ошибки. Мне жаль, что я не смогу наградить за это частичную награду; преобразование этого комментария в ответ еще не было бы полным ответом, но это существенно помогло.)

Оказывается, это была проблематичная строка в файле конфигурации:

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.

Кажется, что существует проблема с документацией к стрельбе, которую я собираюсь сообщить, потому что на момент написания этого документа, документы для v19.2.1 все еще утверждают, что egg:gunicorn#[worker] синтаксис действителен. (В примере используется gevent, но похоже, что он должен применяться к другим типам). Кто знает, это май быть в силе в некоторых случаях, но в моем (пулеметчик в virtualenv, установленный с пипсом), это не так.


1
2018-02-24 05:25