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

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

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

Ничто не изменилось в среде (или virtualenv, который gunicorn выполняет в), только 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.

Попытка выполнить команду gunicorn, содержавшуюся в run.sh (вставляемый ниже), вручную от оболочки, это просто сразу вышло, не производя ошибок с кодом выхода 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")