apache2 FastCGI-коммуникация с динамическим сервером прервана время ожидания при первом чтении

Question

apache2 FastCGI-коммуникация с динамическим сервером прервана время ожидания при первом чтении

Описание: Невозможно запустить любой из самых простых сценариев FastCGI "Hello World", любой запрос всегда заканчивается тайм-аутом. Кажется, что нет никакой связи между сервером и скриптами FastCGI (с использованием динамических скриптов FastCGI).

Окружающая среда

Ubuntu Precise (12.04)
пакет apache2.2-bin
пакет apache2-mpm-prefork
пакет libapache2-mod-fastcgi
пакет libfcgi-perl
пакет python-flup
Несколько сайтов, настроенных как виртуальные хосты на 127.0.0.1
Существует /var/lib/apache2/fastcgi каталог, принадлежащий www-dataДоступно для чтения всем (владелец, группа и другие)
Существует /var/lib/apache2/fastcgi/dynamic каталог, принадлежащий www-data, который ограничен владельцем (читаемый, доступный для записи и доступный для www-data только)
Существует файл индекса / сокета в /var/lib/apache2/fastcgi/ каталог

FastCGI соответствующие конфигурации:

Каталог /etc/apache2/mods-enabled/ содержит ссылку на fastcgi.conf а также fastcgi.load (mod_fastcgi включен).

Файл fastcgi.conf содержит следующее (осталось нетронутым, я его не редактировал):

<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi
  #FastCgiWrapper /usr/lib/apache2/suexec
  FastCgiIpcDir /var/lib/apache2/fastcgi
</IfModule>

Соответствующий файл конфигурации в /etc/apache2/sites-enabled/ содержит следующее (больше ничего нет о специфической конфигурации FastCGI):

<DirectoryMatch /fcgi-bin>
   Options +ExecCGI
   <FilesMatch "^[^\.]+$">
      SetHandler fastcgi-script
   </FilesMatch>
</DirectoryMatch>

Тестовые материалы на тестовом виртуальном хосте:

Там существует fcgi-bin/test-perl.fcgi чей контент (файл является исполняемым для всех и читаемым для владельца и группы):

#!/usr/bin/perl

use CGI::Fast qw(:standard);
    $COUNTER = 0;
    while (new CGI::Fast) {
    print header;
    print start_html("Fast CGI Rocks");
    print
        h1("Fast CGI Rocks"),
        "Invocation number ",b($COUNTER++),
            " PID ",b($$),".",
        hr;
        print end_html;
    }

Там существует fcgi-bin/test-python.fcgi чей контент (файл является исполняемым для всех и читаемым для владельца и группы):

#!/usr/bin/python

def myapp(environ, start_response):
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return ['Hello World!\n']

try:
    from flup.server.fcgi import WSGIServer
    WSGIServer(myapp).run()
except:
    import sys, traceback
    traceback.print_exc(file=open("errlog.txt","a"))

Проблема

Хотя оба fcgi-bin/test-perl.fcgi а также fcgi-bin/test-python.fcgi работает нормально, когда выполняется из командной строки, ни один, кажется, не работает при вызове, например, как http://test.loc/fcgi-bin/test-perl.fcgi или же http://test.loc/fcgi-bin/test-python.fcgi,

Ничего не происходит, и после некоторой задержки я получаю ошибку 500, и журналы ошибок Apache содержат несколько записей, похожих на:

[<date>] [error] [client <IP>] FastCGI: comm with (dynamic) server "/<…>/fcgi-bin/<script>.fcgi" aborted: (first read) idle timeout (30 sec), referer: <referrer>
[<date>] [error] [client <IP>] FastCGI: incomplete headers (0 bytes) received from server "<…>/fcgi-bin/<script>.fcgi", referer: <referrer>

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

Любые указатели и контрольный список приветствуются. Не стесняйтесь спрашивать о любых недостающих деталях, которые вы считаете актуальными или заслуживающими проверки.

Приятного дня.

-- редактировать --

Обновление проблемы

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

На одном и том же виртуальном хосте, то есть с точно такой же конфигурацией сервера, некоторые сценарии, которые абсолютно одинаковы (и имеют точно такие же права доступа), завершаются ошибкой в зависимости от их расположения.

В остальном вот что в конфигурации сайта:

<DirectoryMatch /fcgi-bin>
   Options +ExecCGI
   <FilesMatch "^[^\.]+$">
      SetHandler fastcgi-script
   </FilesMatch>
</DirectoryMatch>

С учетом вышеизложенного, только сценарии в /fcgi-bin обрабатываются как скрипт FastCGI. Но у меня также есть некоторые другие (все еще для тестирования): один в /cgi-bin и один в / (т.е. в public_html каталог). Для этого .htaccess содержит эту запись:

Options +ExecCGI
AddHandler fastcgi-script .fcgi

Таким образом, два других скрипта FastCGI должны работать так же, как /fcgi-bin, но они этого не делают, и в настоящее время они неизменно заканчиваются тайм-аутом соединения, так же, как /fcgi-bin первый сделал.

Это заставляет меня чувствовать, что что-то может быть не так с mod_fastcgi модуль (известная ошибка? еще?). Пока что этот модуль работает довольно случайно.

- редактировать 2 -

Выше в первом редактировании было моей ошибкой: группа была не права с другими сценариями, это должно было быть www-data, но это не так. Так что что-то не так, придерживайтесь ответа, который я дал, то есть попробуйте посмотреть на FastCgiConfigи посмотрите, решит ли он что-нибудь или хотя бы соблюдает параметры тайм-аута.

4

apache2 fastcgi mod-fastcgi apache2-module flup

Источник

user279335 22 мар '13 в 05:16

3 ответа

Другие вопросы по тегам apache2 fastcgi mod-fastcgi apache2-module flup

user279335 22 мар '13 в 07:46 2013-03-22 07:46 · Answer 1 · 2013-03-22 07:46

Я отвечу на свой вопрос, как мне кажется, работает сейчас. Однако эпилог все еще выглядит странно.

Хотя конфигурация по умолчанию должна быть в порядке, я все же хотел еще раз просмотреть документ "Module mod_fastcgi". Поскольку я хотел только динамический FastCGI, я сосредоточился на FastCgiConfig только директива, поэтому намеренно не FastCgiServer а также FastCgiExternalServer директивы.

Как не было FastCgiServer вообще по умолчанию fastcgi.conf файл, я начал пытаться настроить свой собственный. Для первого теста я хотел использовать -appConnTimeout вариант, по крайней мере, попросить сервер не ждать так долго, прежде чем он возвращает мне ошибку 500.

Поэтому я просто добавил это в конфигурацию сайта (я не трогал fastcgi.cong), в том же файле, где настроены виртуальные хосты:

FastCgiConfig -appConnTimeout 2

Это означало, что сервер должен ждать не более 2 секунд вместо 30 секунд ожидания. Я попытался вызвать скрипт FastCGI, чтобы увидеть, работает ли хотя бы эта конфигурация. Я ожидал получить ошибку с задержкой в 2 секунды, но вместо этого скрипт работал без ошибок.

Что странно, так это то, что я затем попытался удалить эту опцию, чтобы проверить, было ли это просто то дополнение, которое просто отсутствовало, чтобы заставить работать скрипты FastCGI. Но после того, как я закомментировал эту опцию, она все еще работала и после полной перезагрузки осталась прежней.

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

Извините, если я не могу объяснить, что именно он сделал. Я действительно хотел бы знать. Сейчас это работает, но я не знаю почему.

user3198209 21 май '14 в 06:46 2014-05-21 06:46 · Answer 2 · 2014-05-21 06:46

#############

fastcgi.conf FastCgiWrapper Off

2

Источник

user3198209 21 май '14 в 06:46

user388354 13 янв '15 в 08:28 2015-01-13 08:28 · Answer 3 · 2015-01-13 08:28

Ответ peng.rl решит мою проблему.

Мой ceph radosgw вообще не может получить информацию от apache. после отключения FastCgiWrapper я могу записывать данные в wireshark.

0

Источник

user388354 13 янв '15 в 08:28