Script время ожидания перед возвратом заголовков: wsgi.py на эластичном бобовом стебле

Ответ 1

ОБНОВЛЕНИЕ 8 FEB 2017

Ранее мой wsgi.conf использовал только один процесс:

WSGIDaemonProcess wsgi процессы = 1 threads = 15 display- name=% {GROUP}

Я поднял процессы к чему-то более разумному и не имел никаких проблем:

WSGIDaemonProcess wsgi процессы = 6 threads = 15 display- name=% {GROUP}

Это изменение вместе с оригинальным добавлением WSGIApplicationGroup %{GLOBAL}, похоже, сделало трюк.

ОБНОВЛЕНИЕ 17 сентября 2015 г.

Я все еще время от времени сталкиваюсь с этой проблемой. Обычно перераспределение через eb deploy устраняет проблему. Трудно сказать, в чем заключается основная проблема.

Оригинальный ответ

В итоге я получил работу над проектом, но затем попытался создать образ для использования в новых экземплярах, что заново открыло проблему. Я не уверен, почему это сработало, но перестало работать, но я восстановил свой собственный AMI с нуля, а затем отменил свой проект. Оказывается, это проблема в wsgi.py. Версия, которую я опубликовал, на самом деле отличается от того, что было развернуто. По какой-то причине другой разработчик поместил это в wsgi.py:

path = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
if path not in sys.path:
sys.path.append(path)

Я удалил это и устранил проблему.

Мой совет для тех, у кого

Script timed out before returning headers: wsgi.py

- проверить файл wsgi.py.

Ответ 2

Это, безусловно, похоже на проблему с WSGI и Apache, как вы упомянули. Одна вещь, чтобы дважды проверить файл .ebextensions в вашем исходном каталоге.

Там должна быть конфигурация, которая указывает информацию WSGI, такую ​​как местоположение приложения. Вы также можете проверить свои настройки Django и запустить его локально с помощью установки Apache с использованием WSGI.

Вы, наверное, уже прочитали официальную документацию для WSGI и Django, но это может привести к некоторым упрощенным вещам, которые вы, возможно, пропустили: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_Python_django.html#create_deploy_Python_django_update

Ответ 3

Только мои 2 цента по аналогичной проблеме, с которой я столкнулся.

У меня была аналогичная проблема. Оказалось, что script (который делает вызов вставки/обновления/удаления DB) выполняется из приложения django, ожидая в состоянии взаимоблокировки блокировки в таблице, которая будет выпущена. Как только он был выпущен, код прошел без этой ошибки. Мне никогда не приходилось повторно развертывать мое приложение EB.

• Убедитесь, что вы не подключены к базе данных через любой другой клиент SQL. Если да, запросите любые активные блокировки. (В моем случае я подключался к красному смещению. В таблице STV_LOCKS перечислены активные блокировки).
• Проверьте, кто держит замки. (В моем случае это был мой клиент SQL, связанный с красным смещением, который выполнял операцию CUD, и поскольку COMMIT не был выпущен, он удерживал ожидающую блокировку записи в таблице).
• Я выпустил коммит от моего SQL-клиента, и блокировка была выпущена. Мой EB-код прошел, и больше не было script ошибка времени.

Ответ 4

Исправление для нас заключалось в том, чтобы добавить параметр WSGIApplicationGroup %{GLOBAL} в соответствии с ответом Meistro.

Вы хотите, чтобы вы отредактировали конфигурацию wsgi с помощью своего файла .ebextensions/foobar.config, чтобы изменения были постоянными. См. документы конфигурации .ebextensions.

Добавьте в свой файл .ebextensions/foobar.config следующее:

files:
  "/etc/httpd/conf.d/wsgi_custom.conf":
    mode: "000644"
    owner: root
    group: root
    content: |
      WSGIApplicationGroup %{GLOBAL}

Это создаст (или перезапишет) содержимое файла /etc/httpd/conf.d/wsgi_custom.conf с помощью WSGIApplicationGroup %{GLOBAL}

Ответ 5

Я пробовал выше шаги, которые могут решить проблему временно. то я сделал следующие шаги:

• создайте файл "packages.config" в папке ".ebextensions" и поместите следующие строки

  WSGIApplicationGroup: command: grep -rnw 'WSGIApplicationGroup' config.py || sed -i.bak '/LogFormat/ a WSGIApplicationGroup %%{GLOBAL}' config.py cwd: /opt/elasticbeanstalk/hooks

спасибо за помощь в том, кто дал предложение об этом типе ошибок

Наконец, я исправил. просто прочитайте о концепции модуля apache mpm load

Я изменил режим загрузки по умолчанию из модуля preache, который зависит от os.

найдите ниже местоположение

местоположение: /etc/httpd/conf.module.d/00-mpm*.

Включить рабочий модуль, который зависит от наших случаев

LoadModule mpm_worker_module lib64/httpd/modules/mod_mpm_worker.so

еще раз спасибо, кто помог мне.

Ответ 6

У меня была эта проблема, пока я не понял, что использую другую версию Python. Позвольте мне объяснить это. Я использовал CentOS 7. Версией Python по умолчанию в CentOS 7 является Python 2.7, но мой код использует Python 3.6, поэтому я установил Python 3.6 на той же машине, выполнив следующее:

sudo yum install centos-release-scl
sudo yum install rh-python36 rh-python36-python-pip rh-python36-python-virtualenv
scl enable rh-python36 bash

Затем создал виртуальную среду и использовал ее в WSGI:

    WSGIScriptAlias   / /var/www/myproject/myproject/wsgi.py
    WSGIDaemonProcess myproject python-home=/var/www/myproject python-path=/var/www/myproject:/var/www/myproject/lib/python3.6/site-packages
    WSGIProcessGroup  myproject    

И появилась проблема "истекло время ожидания сценария". Затем я понимаю, что mod_wsgi.so был скомпилирован с libpython2.7.so.1.0.

# ldd /usr/lib64/httpd/modules/mod_wsgi.so
linux-vdso.so.1 =>  (0x00007ffd3fcae000)
libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f1240cd4000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1240ab8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f12408b3000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f12406b0000)
libm.so.6 => /lib64/libm.so.6 (0x00007f12403ae000)
libc.so.6 => /lib64/libc.so.6 (0x00007f123ffe0000)
/lib64/ld-linux-x86-64.so.2 (0x00005598a5aac000)

Решением было удаление пакета mod_wsgi и установка пакета rh-python36-mod_wsgi.

С наилучшими пожеланиями!