Обзор проблемы (подробности ниже):
У меня возникает проблема интеграции apache2 + ruby при попытке подключиться к источнику данных ODBC. Основная проблема сводится к тому, что скрипты, которые нормально запускаются из интерактивной оболочки, вылетают из Ruby в строке подключения к базе данных при запуске как 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 (11.08.2008, уровень патча 287) [универсальный-darwin9.0] ruby-odbc 0.9997
dbd-odbc (0.2.5)
dbi (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
Вы пробовали дефрагментировать диск?
Подобные проблемы обычно возникают из-за переменной среды, которая определенным образом задается в оболочке, но не устанавливается или устанавливается по-другому, когда скрипт запускается под cgi или cron. Обычно они предполагают путь к файлу или исполняемому файлу.
Однажды у меня была очень похожая проблема с устаревшим веб-приложением на Python, в котором использовалось несколько грубых скриптов cgi. Один из них вылетал из-за странных ошибок загрузчика в журнале apache, таких как:
Failed to load libgcc_s.so.1
Оказывается, в этой конкретной конфигурации apache для сценариев CGI было установлено ограничение в 64 МБ памяти, а для одного конкретного запроса использовалось гораздо больше 64 МБ. Некоторые из модулей расширения были связаны с libgcc_s для потоков pthreads, поэтому к моменту их импорта процесс уже достиг предела и - smackdown!
Я бы проверил RSS вашего скрипта при запуске вручную. Если это большой процесс, попробуйте установить RLimitMEM на что-то большее, например 128 МБ или 256 МБ.
RLimitMEM 128MB