gunicorn 19.2 non riesce a iniziare con la configuration 18.0

Ho un server dev che gestisce gunicorn / Django dietro nginx. Come parte di un più ampio aggiornamento dell'ambiente del server, ho tentato di aggiornare la funivia da 18.0 a 19.2.1, ma il servizio non avrebbe più inizio. (Il server è in esecuzione Arch e quindi utilizza systemctl.)

La configuration del gunicorn è stata fatta da qualcuno che non è più a nostra disposizione e non conosce bene il gunicorn che non è stato in grado di risolvere o persino individuare il problema, quindi sono tornato alla versione 18.0 e sta funzionando per ora. Tuttavia, vorrei aggiornarlo alla fine e get la configuration in una forma in cui functionrebbe. Ho la sensazione che la configuration corrente sia sub-ottimale o ridondante, ma non ho modo di sapere certamente :-).

  • Posso copiare l'intera cartella / var / lib / mysql in un altro server? (mysql vs mariadb, diverse versioni)
  • bashrc non caricato in shell / bin / bash
  • Memorizzazione di chiavi protette sul server web Ubuntu
  • nginx termina la connessione dopo 65 k byte
  • mettendo lo script di shell sotto il controllo systemd
  • Perché non è systemctl avviare redis-server su CentOS 7?
  • Nulla è cambiato nell'ambiente (o il virtualenv che gunicorn è in esecuzione), solo gunicorn è stato aggiornato. Systemctl ha prodotto questo errore su 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. 

    Tentando di eseguire manualmente il command gunicorn in run.sh (incollato in basso) dalla shell, è semplicemente uscito immediatamente senza produrre errori, con un codice di output di 0. Niente è stato registrato. Infatti, sembra che il mio predecessore abbia distriggersto il gunicorn che ha registrato un po 'di tempo dopo che il file di registro è cresciuto ad una dimensione allarmante, ma questo è un problema per un altro giorno.

    Ecco il contenuto dei file rilevanti:

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

    One Solution collect form web for “gunicorn 19.2 non riesce a iniziare con la configuration 18.0”

    (Delle osservazioni inviate alla domanda devo specialmente call quella da skarap , poiché mi ha aiutato a trovare una soluzione da sola facendo gunicorn correttamente errori di output. Vorrei poter aggiudicare una bontà parziale per questo, la conversione di quel commento in una risposta non sarebbe ancora una risposta completa, ma ha contribuito sostanzialmente.)

    Si scopre che questa era la row problematica nel file di configuration:

    worker_class = 'egg:gunicorn#sync'

    Ha causato questo errore:

     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 ] 

    Sostituirlo con worker_class = 'sync' risolto l'import-errore e quindi il problema. Nessuna nuova modifica di configuration era necessaria nell'aggiornamento 18.0 -> 19.2.1.

    Sembra che ci sia un problema con la documentazione di gunicorn, che intendo segnalare, perché al momento della scrittura, i documenti per v19.2.1 dichiarano ancora che l' egg:gunicorn#[worker] è valida. (L'esempio che utilizza gevent, ma sembra che dovrebbe applicarsi ad altri tipi). Chi sa, può essere valido in alcune circostanze, ma nella mia (gunicorn in virtualenv, installato con pip), non lo è.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.