WSGI: усеченные или увеличенные заголовки ответа, полученные от процесса демона

Причина проблемы была тупой.

Известно, что модули расширения Python C, такие как numpy, вызывают тайм-ауты при использовании в mod_wsgi.

Источник: ответ Шон Ф на Тайм-аут при чтении заголовков ответа от процесса-демона

На аналогичный вопрос, который я не нашел при первоначальном поиске, ответил и объяснил автор mod_wsgi говорит -

Некоторые сторонние пакеты для Python, которые используют модули расширения C, в том числе scipy и numpy, будут работать только в основном интерпретаторе Python и не могут использоваться во вспомогательных интерпретаторах, поскольку по умолчанию используется mod_wsgi. Результатом может быть взаимоблокировка потоков, неправильное поведение или сбои процессов.

Источник: ответ Грэм Дамплтон на Не отвечает apache + mod_wsgi после установки scipy

Решение

Добавьте строку ниже в свой httpd.conf. В моем случае файл был /etc/apache2/apache2.conf.

WSGIApplicationGroup %{GLOBAL}

Как уже упоминалось, это вызвано сбоями процесса по ряду потенциальных причин. Одна из причин заключается в том, что некоторые зависимости Python не являются потокобезопасными.

Если проблема в этом, можно обойтись без изменения типа MPM Apache. Тип prefork не использует потоки, поэтому, если проблема заключается в большом количестве сбоев из-за неправильного использования потока, это должно исправить. Типы worker и event используют меньше памяти, но также используют потоки, поэтому они могут столкнуться с этой ошибкой.

Чтобы определить, какой тип вы используете в настоящее время, запустите:

apachectl -V | grep -i mpm

Если ты видишь Server MPM: prefork значит, вы уже используете prefork, то есть причина ошибки может быть в чем-то другом. Если там написано "worker" или "event", то вы можете переключиться на префорк, запустив:

sudo a2dismod mpm_event
sudo a2dismod mpm_worker
sudo a2enmod mpm_prefork
sudo service apache2 restart

Обратите внимание, что основным недостатком prefork является то, что, поскольку он не использует потоки, он потребляет больше памяти.

Изменить: с тех пор я столкнулся с этой ошибкой по другим причинам. Совсем недавно проблема вызвана ошибкой в ​​предварительно скомпилированном системном пакете Ubuntu mod-wsgi, а также ошибкой в ​​пакете Python psycopg2.

Решением для этого было переключиться с системного mod-wsgi на пакет Python, а также на пакет psycopg2-binary:

sudo apt purge libapache2-mod-wsgi*
sudo apt install apache2-dev
pip uninstall psycopg2
pip install mod_wsgi psycopg2-binary

Мне также пришлось обновить файл конфигурации моего сайта apache, добавив вверху:

LoadModule wsgi_module /usr/local/myproject/.env/lib/python2.7/site-packages/mod_wsgi/server/mod_wsgi-py27.so

И измените мой оператор WSGIDaemonProcess, чтобы использовать python-home вместо python-path, на что-то вроде:

WSGIDaemonProcess myproject python-home=/usr/local/myproject/.env processes=5 threads=15 display-name=%{GROUP} user=www-data group=www-data

Я столкнулся с этим как для Python2.7, так и для Python3.7, и решение такое же, но путь к mod_wsgi.so меняется.

Я получил аналогичную ошибку при попытке запустить opencv с использованием mod_wsgi и apache. Я предполагаю, что проблема, вероятно, заключалась в нескольких потоках с базовым кодом C, которые пытались получить GIL и терпели неудачу.

Я решил это, установив thread = 1 и process = 32 (в моем случае это было уместно) в директиве WSGIDaemonProcess.

PS: Поздно на вечеринку, но подумал, что это может кому-то помочь.

Я получил это из доступа Python к magic (libmagic). Некоторые версии magic вести себя так. Я просто скомпилировал версию и использовал ее вместо той, которая была в ОС, по какой-то причине это решило.

В моем случае мне пришлось изменить строку WSGIDaemonProcess с:

WSGIDaemonProcess wsgi processes=2 threads=4 display-name=%{GROUP} \
  python-path=/var/www/appname:/var/www/appname/venv/lib/python2.7/site-packages user=wsgi group=wsgi \
  home=/var/www/appname

кому:

WSGIDaemonProcess appname user=wsgi group=wsgi processes=2 threads=4 display-name=%{GROUP} home=/var/www/appname

В моем случае проблема была в пимонго и PHP. Как описано в этой проблеме GitHub https://github.com/GrahamDumpleton/mod_wsgi/issues/351:

Если PHP загружает клиент для MongoDB, он может [создать конфликт]. (...) PHP часто предварительно загружает все расширения. Не имеет значения, использует ли его размещенное приложение.

Как я это решил:

1. Я запустил свое приложение для фляги из mod_wsgi-express: mod_wsgi-express start-server api.wsgi --user=www-data --group=www-data --host=0.0.0.0 --port=8443.
2. Затем в моем httpd.conf, Я перенаправил весь трафик на псевдоним своего фляжного приложения, используя:

SSLEngine on
SSLProxyEngine On
ProxyPass /api http://localhost:8443/
ProxyPassReverse /api http://localhost:8443/