Назад | Перейти на главную страницу

Обновление Ubuntu сломало django mod_wsgi

Я бьюсь здесь головой и, кажется, нигде не могу найти ответы.

На моем сервере работает Ubuntu 14.04. Я запускаю несколько сайтов django с использованием apache и mod_wsgi. Сегодня после обновления сайты не будут работать.

Я вижу, что libapache2-mod-wsgi: amd64 (3.4-4ubuntu2.1.14.04.1, 3.4-4ubuntu2.1.14.04.2) - одно из обновлений

Эта ошибка появляется в журнале ошибок apache

mod_wsgi (pid=6624): Failure to configure the daemon process correctly and
  process left in unspecified state. Restarting daemon process after delay.

Хотя это отображается в конкретном журнале приложения django

Fatal Python error: PyEval_AcquireThread: NULL new thread state
<...>
Script timed out before returning headers: wsgi.py

Я не могу вспомнить, установил ли я mod_wsgi с помощью pip или нет.

Любые указатели были бы замечательными.

На всякий случай, если вы еще не решили это:

В mod_wsgi 2.0+ вам необходимо указать домашний каталог при использовании директивы WSGIDaemonProcess. В моем случае я использовал пользователя без домашнего каталога, и это вызывало ту же ошибку, которую вы видели.

home = каталог

Определяет абсолютный путь к каталогу, который должен использоваться в качестве начального текущего рабочего каталога процессов демона в группе процессов. Если этот параметр не определен, в mod_wsgi 1.X текущий рабочий каталог родительского процесса Apache будет унаследован процессами демона в группе процессов. Обычно текущий рабочий каталог родительского процесса Apache является корневым каталогом. В mod_wsgi 2.0+ начальный текущий рабочий каталог будет установлен как домашний каталог пользователя, от имени которого запускается процесс демона.

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

Поведение текущего рабочего каталога для режима демона со временем изменилось.

Давным-давно все, что Apache установил для текущего рабочего каталога, будет использоваться. Обычно это '/'.

Затем он был изменен, чтобы попытаться использовать рабочий каталог пользователя, от имени которого работал процесс демона. Если у этого пользователя не было действительного домашнего каталога, как это иногда бывает с пользователем Apache по умолчанию, он молча завершился неудачей, и вы все равно остались бы с ним как в '/'.

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

Это вызвало дальнейшее изменение, так что домашний каталог будет использоваться только в том случае, если пользователь, выполняющий процесс демона, не является пользователем Apache по умолчанию. Если вы явно устанавливали пользователя для процесса демона на пользователя, отличного от Apache, и у него не было домашнего каталога, вам нужно было бы предпринять действия, чтобы установить опцию «home».

Поэтому похоже, что вы используете не последнюю версию mod_wsgi, а версию с предпоследним поведением.

Поскольку некоторые дистрибутивы Linux обратно портировали некоторые из связанных изменений в гораздо более старые версии mod_wsgi, когда это даже не было проблемой безопасности, которая требовала обратного переноса изменений, они создали некоторый беспорядок, поскольку они никогда не использовали последнее изменение для решения у этого пользователя Apache нет домашнего каталога.

Итак, в конечном итоге ваша проблема вызвана тем, что ваш дистрибутив Linux использует устаревший mod_wsgi и, возможно, обратно перенесенный неполный набор изменений.

Обходной путь для вас - установить home = '/' как параметр для WSGIDaemonProcess.

Еще лучше, каким-то образом обновитесь до последней версии mod_wsgi вместо старой версии, которую использует ваш дистрибутив Linux.

Последняя версия mod_wsgi 4.4.8. Ваш дистрибутив Linux поставляется с версией, отстающей более чем на 20 версий, поэтому вы упускаете множество исправлений ошибок и улучшений.

Похоже, что mod_wsgi не запустится, если демон не имеет прав доступа к своим рабочим каталогам. Из исходного кода:

if (wsgi_setup_access(daemon) == -1) {

         /*
          * If we get any failure from setting up the appropriate
          * permissions or working directory for the daemon process
          * then we exit the process. Don't die immediately to avoid
          * a fork bomb.
          */

         ap_log_error(APLOG_MARK, APLOG_ALERT, 0, wsgi_server,
                      "mod_wsgi (pid=%d): Failure to configure the "
                      "daemon process correctly and process left in "
                      "unspecified state. Restarting daemon process "
                      "after delay.", getpid());
         sleep(20);

         wsgi_exit_daemon_process(-1);
     }