Сбой Apache2 cgi при доступе к odbc db (но работает нормально из оболочки)
Обзор проблемы (подробности ниже):
У меня возникла проблема интеграции apache2 + ruby при попытке подключения к источнику данных ODBC. Основная проблема сводится к тому, что сценарии, которые хорошо работают из интерактивного рубина аварийного завершения оболочки на соединительной линии базы данных, запускаются как cgi из apache2. Ruby cgi, которые не пытаются получить доступ к источнику данных ODBC, работают нормально. И (опять же) сценарии ruby, которые подключаются к базе данных с ODBC, прекрасно работают при запуске из командной строки (или cron). Это поведение идентично, когда я использую Perl вместо Ruby.
Итак, проблема, похоже, связана со средой, предоставленной для ruby (perl) apache2, но я не могу понять, что не так или что с этим делать.
У кого-нибудь есть какие-либо предложения о том, как заставить эти сценарии cgi работать должным образом?
Я пробовал много разных вещей, чтобы заставить это работать, и я рад предоставить более подробную информацию о любом аспекте, если это поможет.
Подробности:
Mac OS X Server 10.5.8 Xserve 2 x 2.66 Двухъядерный Intel Xeon (12 ГБ) Apache 2.2.13
ruby 1.8.6 (2008-08-11, уровень обновления 287) [universal-darwin9.0] ruby-odbc 0.9997
dbd-odbc (0.2.5)
дБи (0,4,3)
mod_ruby 1.3.0
Perl - 5.8.8
DBI - 1,609
DBD:: ODBC - 1,23
Драйвер odbc: DataDirect SequeLink v5.5 (/Library/ODBC/SequeLink.bundle/Contents/MacOS/ivslk20.dylib)
Источник данных odbc: FileMaker Server 10 (v10.0.2.206)
) минимальная версия скрипта (анонимная), которая будет зависать в apache, но успешно запускается из оболочки:
#!/usr/bin/ruby
require 'cgi'
require 'odbc'
cgi = CGI.new("html3")
aConnection = ODBC::connect('DBFile', "username", 'password')
aQuery = aConnection.prepare("SELECT zzz_kP_ID FROM DBTable WHERE zzz_kP_ID = 81044")
aQuery.execute
aRecord = aQuery.fetch_hash.inspect
aQuery.drop
aConnection.disconnect
# aRecord = '{"zzz_kP_ID"=>81044.0}'
cgi.out{
cgi.html{
cgi.body{
"<pre>Primary Key: #{aRecord}</pre>"
}
}
}
Пример запуска этого из оболочки:
gamma%./minimal.rb (автономный режим: введите имя = пары значений при стандартном вводе) Content-Type: text / html Content-Length: 134
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><HTML><BODY><pre>Primary Key: {"zzz_kP_ID"=>81044.0}</pre></font></BODY></HTML>% gamma%
) типичные строки журнала аварий:
22 декабря 14:02:38 gamma ReportCrash[79237]: составление отчета о сбое для процесса perl[79236]
22 декабря 14:02:38 gamma ReportCrash[79237]: сохраненный аварийный отчет в /Library/Logs/CrashReporter/perl_2009-12-22-140237_HTCF.crash с использованием uid: 0 gid: 0, euid: 0 egid: 0
22 декабря 14:03:13 gamma ReportCrash[79256]: составление отчета о сбое для процесса perl[79253]
22 декабря 14:03:13 gamma ReportCrash[79256]: сохраненный аварийный отчет в /Library/Logs/CrashReporter/perl_2009-12-22-140311_HTCF.crash с использованием uid: 0 gid: 0, euid: 0 egid: 0
3 ответа
Подобные проблемы обычно возникают из-за переменной среды, которая задается определенным образом в оболочке, но сбрасывается или устанавливается по-разному, когда скрипт запускается в cgi или cron. Обычно они предполагают путь к файлу или исполняемому файлу.
Однажды у меня была очень похожая проблема с устаревшим веб-приложением на python, которое использовало пару gnarly cgi-скриптов. Одна из них вылетала со странными ошибками загрузчика в журнале apache, такими как:
Failed to load libgcc_s.so.1
Оказывается, что в этой конкретной конфигурации apache скрипты CGI, по-видимому, имели ограничение в 64 МБ памяти, и один конкретный запрос использовал намного больше, чем 64 МБ. Некоторые модули расширения были связаны с libgcc_s для pthreads, поэтому к моменту их импорта процесс уже был на пределе и - smackdown!
Я бы проверил RSS вашего скрипта при запуске вручную. Если это большой процесс, попробуйте установить RLimitMEM на что-то большее, например 128 МБ или 256 МБ.
RLimitMEM 128MB