Django - Край на изхода на скрипта преди заглавките

Basic hello.wsgi работи добре. Друго приложение на django също работи перфектно с абсолютно същата версия на virtualenv.

mod_wsgi виси за ~10 минути (!!!) и виждам, че нищо не може да ми посочи проблем (отстраняване на грешки на нивото на журнал):

[Tue Mar 25 23:11:08.878578 2014] [:info] [pid 4719:tid 140720591648640] mod_wsgi (pid=4719): Attach interpreter ''.
[Tue Mar 25 23:11:08.879171 2014] [:info] [pid 4717:tid 140720591648640] mod_wsgi (pid=4717): Attach interpreter ''.
[Tue Mar 25 23:11:10.891348 2014] [authz_core:debug] [pid 4730:tid 140720477226752] mod_authz_core.c(802): [client 127.0.0.1:40844] AH01626: authorization result of Require all granted: granted
[Tue Mar 25 23:11:10.891391 2014] [authz_core:debug] [pid 4730:tid 140720477226752] mod_authz_core.c(802): [client 127.0.0.1:40844] AH01626: authorization result of <RequireAny>: granted
[Tue Mar 25 23:11:10.891489 2014] [authz_core:debug] [pid 4730:tid 140720477226752] mod_authz_core.c(802): [client 127.0.0.1:40844] AH01626: authorization result of Require all granted: granted
[Tue Mar 25 23:11:10.891497 2014] [authz_core:debug] [pid 4730:tid 140720477226752] mod_authz_core.c(802): [client 127.0.0.1:40844] AH01626: authorization result of <RequireAny>: granted
[Tue Mar 25 23:11:10.903921 2014] [:info] [pid 4719:tid 140720469034752] mod_wsgi (pid=4719): Create interpreter 'prj-dev|'.
[Tue Mar 25 23:11:10.905378 2014] [:info] [pid 4719:tid 140720469034752] [remote 127.0.0.1:57616] mod_wsgi (pid=4719, process='prj.project-dev', application='prj-dev|'): Loading WSGI script '/var/www/prj.project-dev/venv/www/public/index.wsgi'.
[Tue Mar 25 23:11:12.014799 2014] [:error] [pid 4719:tid 140720469034752] /usr/lib/python2.7/dist-packages/numpy/oldnumeric/__init__.py:11: ModuleDeprecationWarning: The oldnumeric module will be dropped in Numpy 1.9
[Tue Mar 25 23:11:12.014843 2014] [:error] [pid 4719:tid 140720469034752]   warnings.warn(_msg, ModuleDeprecationWarning)
[Tue Mar 25 23:11:12.014846 2014] [:error] [pid 4719:tid 140720469034752] 
[Tue Mar 25 23:16:11.888631 2014] [:info] [pid 4719:tid 140720485820160] mod_wsgi (pid=4719): Daemon process deadlock timer expired, stopping process 'prj.project-dev'.
[Tue Mar 25 23:16:11.888761 2014] [:info] [pid 4719:tid 140720591648640] mod_wsgi (pid=4719): Shutdown requested 'prj.project-dev'.
[Tue Mar 25 23:16:16.889065 2014] [:info] [pid 4719:tid 140720121513728] mod_wsgi (pid=4719): Aborting process 'prj.project-dev'.
[Tue Mar 25 23:16:16.895499 2014] [core:error] [pid 4730:tid 140720477226752] [client 127.0.0.1:40844] End of script output before headers: index.wsgi
[Tue Mar 25 23:16:17.160980 2014] [:info] [pid 5295:tid 140720591648640] mod_wsgi (pid=5295): Attach interpreter ''.

Конфигурацията на Apache също не съдържа нищо интересно. Същата конфигурация работи на друг сървър.

<VirtualHost *:80>
    ServerName prj-dev
    ServerAdmin [email protected]
    DocumentRoot "/var/www/prj.project-dev/venv/www/public"
    ErrorLog /var/log/apache2/prj.project-dev/error_log
    CustomLog /var/log/apache2/prj.project-dev/access_log common

    Alias /media/ /var/www/prj.project-dev/venv/prj/prj/media/
    Alias /static/ /var/www/prj.project-dev/venv/prj/prj/static/
    Alias /usermedia/ /var/www/prj.project-dev/venv/prj/prj/usermedia/

    <Directory /var/www/prj.project-dev/venv/prj/prj/usermedia>
        Order deny,allow
        Allow from all
    </Directory>

    <Directory /var/www/prj.project-dev/venv/prj/prj/media>
        Order deny,allow
        Allow from all
    </Directory>

    <Directory /var/www/prj.project-dev/venv/prj/prj/static>
        Order deny,allow
        Allow from all
    </Directory>

    WSGIDaemonProcess prj.project-dev user=user group=user processes=2 threads=2 display-name=%{GROUP}
    WSGIProcessGroup prj.project-dev
    WSGIScriptAlias / /var/www/prj.project-dev/venv/www/public/index.wsgi

    XSendFile on

    <Directory /var/www/prj.project-dev/venv/www/public>
        Order deny,allow
        Allow from all
    </Directory>

</VirtualHost>

Нищо интересно в wsgi:

import os, sys

activate_this = '/var/www/prj.project-dev/venv/bin/activate_this.py'
execfile(activate_this, dict(__file__=activate_this))
sys.path = [
    '/var/www/prj.project-dev/venv/lib/python2.7/site-packages/',
    '/var/www/prj.project-dev/venv/prj/',
    '/var/www/prj.project-dev/venv/',
] + sys.path

os.environ['DJANGO_SETTINGS_MODULE'] = 'prj.settings'

import django.core.handlers.wsgi
#from raven.contrib.django.middleware.wsgi import Sentry

application = django.core.handlers.wsgi.WSGIHandler()
#application = Sentry(django.core.handlers.wsgi.WSGIHandler())

Въпросът ми е: как мога да разбера истинската причина, поради която виси?


person night-crawler    schedule 25.03.2014    source източник
comment
Създайте отделен въпрос и избройте модулите, които използвате, като изход с pip feeze и вероятно можете лесно да идентифицирате проблемните.   -  person Graham Dumpleton    schedule 13.03.2017


Отговори (4)


Това се покрива от документацията на mod_wsgi.

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Накратко, вероятно използвате модул за разширение на Python, който не е внедрен, за да работи правилно в подинтерпретатор на Python. Това или модулът за разширение не освобождава правилно GIL, когато извършва блокиращи операции. И двете могат да доведат до блокиране на интерпретатора.

Използвайте решението в документацията и вижте дали това помага.

person Graham Dumpleton    schedule 26.03.2014
comment
Благодаря Ви за отговора. Случайно открих защо се случва, докато почиствам импортирането в проекта: в един модул импортирах локална библиотека с текущия префикс на приложението (също е в sys.path): app.permissions. След това го промених на permissions и проработи. Изглежда като кръгово импортиране, но не е имало тези проблеми с предишната версия на apache 2.2.2 && mod_wsgi. Също така нямаше този бъг с django runserver. И все още нямам идея как да го хвана без инциденти. Може да се използва обвивка на Profiler около приложението, за да видите повечето трудни повиквания? Но ще произведе ли резултат, ако wsgi го убие? - person night-crawler; 26.03.2014
comment
Това не звучи правилно. Циркулярният импорт не трябва да води до блокиране. - person Graham Dumpleton; 28.03.2014
comment
Знам, че имам този проблем с matplotlib. Print_figure на Matplotlib възпроизводимо виси с горното съобщение за грешка при изчакване. WSGIApplicationGroup %{GLOBAL} помага. Всичко със стандартните пакети на Ubuntu 14.10. Известен проблем? - person Torsten Bronger; 08.05.2015
comment
Да, matplotlib е един пакет, за който е известно, че има този проблем. - person Graham Dumpleton; 09.05.2015
comment
@TorstenBronger трябва да намериш отговор от това - person User; 17.03.2017
comment
Благодаря ви много за това! Има ли някакъв ресурс, който съставя списък с пакети с известни проблеми с GIL като този? Сблъсквам се с подобен проблем с приложение на Flask, въпреки че имам WSGIApplicationGroup %{GLOBAL}, както е описано във връзката. - person Sean Easter; 24.07.2017
comment
Ако имате нещо, което изглежда е подобен проблем, задайте нов въпрос за него и го обяснете, плюс предоставете вашата mod_wsgi конфигурация. Не е необичайно хората да объркат конфигурацията си, така че WSGIApplicationGroup %{GLOBAL} да не се използва, както си мислят. - person Graham Dumpleton; 25.07.2017

<VirtualHost *:80>
    ServerName localhost
    ServerAlias localhost
    ServerAdmin [email protected]

    <Directory /var/www/mysite/mysite>
    AddHandler wsgi-script .py
    Options +ExecCGI
    </Directory>

    DocumentRoot /var/www/mysite
    WSGIDaemonProcess myproject python-path=/var/www/mysite:/var/www/environ/lib/python2.7/site-packages
    #WSGIProcessGroup mysite
    WSGIScriptAlias / /var/www/mysite/mysite/wsgi.py

    WSGIApplicationGroup %{GLOBAL}

    <Directory /var/www/mysite/mysite/>


    order deny,allow
    Allow from all
    </Directory>

I also had the same error and I have solved this issue by using this configuration.

Също така добавете следния ред към /etc/apache2/apache.config

#WSGIPythonPath /var/www/mysite
person raghavyadav990    schedule 07.12.2015

Знам, че тази тема е на три години, но се натъкнах на нея, когато имах подобен проблем, така че реших да добавя своето решение. В моя случай беше нещо във виртуалната среда, което изискваше mod_ssl да бъде активиран в Apache, въпреки че нито един от сайтовете не използваше SSL (е, те го правят, но той е прекратен другаде). Така

a2enmod ssl
service apache2 restart

Поправих го.

person Paul Turton    schedule 20.05.2017

След като се разрових в отговорите по-горе. Трябваше да задам броя на процесите от 5 на 1. Също така използвах мулти работния mpm.

LoadModule mpm_worker_module modules/mod_mpm_worker.so
WSGIDaemonProcess music user=apache group=apache processes=1 threads=30  python-path=/srv/www/music/service/venv/lib/python2.7/site-packages
person Pat W    schedule 31.05.2017
comment
Това само по себе си не би трябвало да има значение, то налага WSGIApplicationGroup %{GLOBAL}, което почти винаги е отговорът на този проблем. Прочетете също modwsgi.readthedocs.io/en/develop/user -guides/ относно настройването на виртуалната среда по предпочитан начин. Не използвайте python-path, за да го направите. - person Graham Dumpleton; 31.05.2017