Apakah gunicorn dipasang di dalam virtualenv atau di luar?

di dalam. sekarang saya pikir ini adalah masalah aplikasi karena gunicorn dimulai ketika saya membuang sebagian besar pengaturan, hanya saja Anda tidak dapat mengetahui apa yang gagal ketika melihat output itu.

Coba dengan "--debug --log-level debug". Lihat apakah Anda mendapatkan info lebih lanjut.

ini adalah output dengan level log debug, saya khawatir

:kecewa:
Saya belum yakin apa yang terjadi. Setelah pesan "Pekerja booting", saya berharap melihat "Pengecualian dalam proses pekerja" jika ada masalah. Baru lewat tengah malam di sini, tapi aku akan tidur dan mungkin memikirkan sesuatu.

Terima kasih kawan, jika saya mencari tahu sendiri, saya akan memberi tahu Anda. saya sekarang bekerja melalui settings.py menyalakan barang-barang sampai saya menemukan kesalahan lagi. Debug sekolah lama :)

@benoitc mengapa log.exception tidak berfungsi?

Saya biasanya tidak suka menggunakan yang itu karena ini hanya hal python jika itu masuk akal.

Debug terdengar lebih tepat di sana. Tambahan sebenarnya ada traceback :)

Sebenarnya saya mengalami masalah serupa dan saya pikir ini ada hubungannya dengan izin menulis pada file log. Jika saya membuat file log (stderr dan stdout) dapat ditulisi secara publik, sepertinya itu berfungsi dengan baik. Jadi saya rasa itu membawa saya ke pertanyaan ketika Anda pertama kali memulai gunicorn dari supervisord, file log dibuat di bawah root sebelum gunicorn mengambil alih. Apa cara terbaik untuk mengelola memastikan bahwa file log dibuat oleh gunicorn dan bukan oleh supervisord?

Bagaimana Anda meluncurkan gunicorn? Apakah Anda mereproduksinya dengan kepala terakhir?

Saya meluncurkannya dengan supervisord. Ini konfigurasi gunicorn saya untuk supervisord:

[program:sliceweb]
direktori = /opt/src/slicephone/webapp/webapp/
perintah = /opt/src/slicephone/webapp/scripts/gunicorn.sh
stdout_logfile = /opt/logs/supervisord.stdout.log
stderr_logfile = /opt/logs/supervisord.stderr.log

Dan skrip gunicorn yang sebenarnya (perhatikan bagaimana saya menyentuh dan memberikan file log ke pengguna/grup gunicorn):

!/bin/bash

set -e
DATASTORE_SOFTWARE="XXXXX"
ACCESS_LOGFILE=/opt/logs/gunicorn.slice.access.log
ERROR_LOGFILE=/opt/logs/gunicorn.slice.error.log
LOGFILE=/opt/logs/gunicorn.slice.log
LOGDIR=$(namadirektori $LOGFILE)
WEBAPPDIR=$(namadirektori $0)/../
NUM_WORKERS=3
DEBUG_FLAGS="--debug --log-level debug"

pengguna/grup untuk dijalankan sebagai

USER=www-data
GROUP=www-data
cd $WEBAPPDIR/webapp
tes -d $LOGDIR || mkdir -p $LOGDIR
gema WebAppDir: $WEBAPPDIR
echo "Pengguna: $USER"
echo "Grup: $GROUP"

sentuh $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE
chown -R $USER:$GROUP $ACCESS_LOGFILE $ERROR_LOGFILE $LOGFILE

ekspor DATASTORE_SOFTWARE=$DATASTORE_SOFTWARE ; exec /opt/virtenvs/django_slice/bin/gunicorn_django $DEBUG_FLAGS -w $NUM_WORKERS --user=$USER --group=$GROUP --log-level=debug --log-file=$LOGFILE --access-logfile= $ACCESS_LOGFILE --error-logfile=$ERROR_LOGFILE

Pertanyaan bagus tentang kepala terbaru. pip freeze menunjukkan 0,14.1 (.2 terbaru bukan?)

Sudahkah Anda memecahkan masalah? Saya memiliki masalah yang sama dan saat ini saya tidak tahu bagaimana menyelesaikannya.

Harus diselesaikan ya. Versi gunicorn mana yang Anda jalankan? Bisakah Anda memberi saya informasi lebih lanjut tentang konfigurasi Anda sehingga saya dapat mereproduksinya? Terima kasih.

@panyam apakah anda mencoba dengan 0.14.3 ?

@benoitc Maaf sobat saya tidak mencobanya di 0.14.3. Saya berhasil membuatnya bekerja pada 0.14.1 dengan menjadikan pengguna gunicorn sebagai pemilik file log segera setelah supervisord memulai skrip.

Hanya untuk memperjelas, saya tidak berpikir ini adalah masalah gunicorn. @anyeguyue - tempat terbaik untuk memeriksa ini adalah dengan melihat log supervisord atau log gunicorn (biasanya di /var/log/gunicorn/....) untuk melihat apakah Anda memiliki kesalahan "izin ditolak" di sana.

Saya baru saja mendapatkan masalah yang sama, diselesaikan dengan 'python manage.py syncdb' pertama yang menyebabkan kesalahan. Setelah memperbaiki masalah pengaturan itu, gunicorn berfungsi (setelah memulai ulang nginx).

Saya memecahkan masalah ini juga tetapi dengan cara yang berbeda. Baris pertama dari file gunicorn_django adalah "#!/opt/Django/env/mysite/bin/python", yang merupakan jalur jalur python virtualenviroment saya. Masalah diselesaikan dengan menggantinya sebagai "#!/usr/bin/env python", meskipun keduanya menggunakan juru bahasa python yang sama, tetapi ada beberapa perbedaan PYTHONPATH, itu sebabnya gagal sebelumnya.

@anyeguyue Saya menghadapi masalah yang sama pada gunicorn 0.14.5 dan Django 1.4, tetapi dengan gejala yang lebih buruk: gunicorn_django -b 0.0.0.0:8000 menolak untuk dijalankan. Perbaikan Anda berhasil, dan cukup jelas: orang harus selalu bertanya /usr/bin/env python akan digunakan! Terima kasih.

@asimihsan， senang bisa membantu

Saya juga punya masalah ini. Ternyata ada masalah dengan impor yang salah dalam kode saya. Jika Anda ingin men-debug coba jalankan gunicorn_Django --preload - ini diharapkan akan mengeluarkan pengecualian yang tepat.

Bagi siapa pun yang menghadapi masalah yang sama, masalahnya biasanya ada di Django itu sendiri.
Aktifkan venv Anda dan jalankan ./manage.py runserver

Ini biasanya akan memberi Anda pesan kesalahan yang lebih rinci.

:+1: @fergalmoran Membantu saya memecahkan masalah saya (itu adalah masalah dengan PIL)

Saya menghadapi masalah yang sama ... dan tidak tahu bagaimana menyelesaikannya

@pythdasch ada beberapa masalah berbeda yang dibicarakan di sini. Jika Anda dapat memberikan beberapa informasi lebih lanjut, silakan buka tiket baru, atau cukup kirim pesan ke milis dan orang lain mungkin dapat membantu Anda melakukan debug.

Saya pikir kita memecahkan @pythdasch masalah 's di #gunicorn. @pythdasch , dapatkah Anda mengonfirmasi?

Saya konfirmasi, terima kasih kepada berker :)

wsgi saya berada di folder yang sama dengan manage.py saya jadi saya harus meletakkan path wsgi:application dan bukan project. wsgi:aplikasi

(Itu adalah jalur yang salah ke wsgi. Dalam hal ini harus wsgi:application bukan project.wsgi:application)

@tilgovi ya maaf saya pergi ke saluran irc gunicorn untuk menyelesaikannya :)

Saya mengalami masalah yang sama kemarin, dengan gunicorn 0.18 dan permintaan berikut:

gunicorn 'app:create_app()' --name X --workers 5 --user=apprunner --group=apprunner --bind='0.0.0.0:5000' --log-config=resource/config/di/logging.conf --timeout=360 --debug --log-level debug

Itu karena ImportError di aplikasi Flask saya. Kesimpulannya di sini adalah gunicorn tidak menampilkan traceback dari aplikasi jika pekerja mogok saat boot, jadi saya harus memulai aplikasi Flask secara manual untuk melihat masalah sebenarnya.

Saya ingin tahu apakah kita bisa membuatnya menampilkan traceback yang sebenarnya

Ini akan sangat bagus. IMO, hal terbaik berikutnya, jika menampilkan traceback asli tidak memungkinkan, akan menyertakan pesan yang menyarankan untuk menjalankan aplikasi secara langsung, daripada menggunakan gunicorn, untuk mencari kesalahan yang sebenarnya.

Jika saya memahami masalahnya dengan benar, Gunicorn sudah menunjukkan pesan pengecualian seperti ImportError:

$ gunicorn a:app --error-logfile=- --access-logfile=-
[2014-12-10 17:13:31 +0000] [12176] [INFO] Starting gunicorn 19.2.0
[2014-12-10 17:13:31 +0000] [12176] [INFO] Listening at: http://127.0.0.1:8000 (12176)
[2014-12-10 17:13:31 +0000] [12176] [INFO] Using worker: sync
[2014-12-10 17:13:31 +0000] [12181] [INFO] Booting worker with pid: 12181
[2014-12-10 17:13:31 +0000] [12181] [ERROR] Exception in worker process:
Traceback (most recent call last):
  File "/home/berker/projects/gunicorn/gunicorn/arbiter.py", line 517, in spawn_worker
    worker.init_process()
  File "/home/berker/projects/gunicorn/gunicorn/workers/base.py", line 117, in init_process
    self.wsgi = self.app.wsgi()
  File "/home/berker/projects/gunicorn/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/home/berker/projects/gunicorn/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/home/berker/projects/gunicorn/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/home/berker/projects/gunicorn/gunicorn/util.py", line 355, in import_app
    __import__(module)
  File "/home/berker/projects/testdjango/a.py", line 1, in <module>
    from flask import Flask
ImportError: No module named flask

dan jenis pesan kesalahan lainnya:

$ gunicorn a:app --error-logfile=- --access-logfile=-
[2014-12-10 17:18:52 +0000] [12294] [INFO] Starting gunicorn 19.2.0
[2014-12-10 17:18:52 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:52 +0000] [12294] [ERROR] Retrying in 1 second.
[2014-12-10 17:18:53 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:53 +0000] [12294] [ERROR] Retrying in 1 second.
[2014-12-10 17:18:54 +0000] [12294] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2014-12-10 17:18:54 +0000] [12294] [ERROR] Retrying in 1 second.

Saya menghadapi masalah yang sama ketika saya mencoba menjalankan aplikasi seperti ini:

gunicorn app:application -b localhost:3000

Masalahnya adalah keberadaan direktori bernama app juga selain file app.py . Ini berfungsi setelah mengganti nama file python.

@brouberol Saya menemukan masalah yang sama bahkan sekarang. Ketika aplikasi Flask memiliki beberapa modul yang menyebabkan kesalahan impor, Gunicorn tidak akan mencatat traceback tetapi server built-in Flask bisa.

Yang bisa kita lakukan adalah jika Gunicorn gagal mem-boot pekerja tanpa informasi lebih spesifik di log kesalahan apa pun, coba dulu server bawaan Flask.

jalankan guncorn dengan --preload dapat melihat log kesalahan

Bagi saya, Django runserver bekerja dengan baik. Masalahnya adalah mengimpor Django settings dalam file gunicorn.conf.py . Menghapus impor itu memecahkan masalah.