Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Problem overview (details below):

I'm having an apache2 + ruby integration problem when trying to connect to an ODBC data source. The main problem boils down to the fact that scripts that run fine from an interactive shell crash ruby on the database connect line when run as a cgi from apache2. Ruby cgi's that don't try to access the ODBC datasource work fine. And (again) ruby scripts that connect to a database with ODBC do fine when executed from the command line (or cron). This behavior is identical when I use perl instead of ruby.

So, the issue seems to be with the environment provided for ruby (perl) by apache2, but I can't figure out what is wrong or what to do about it.

Does anyone have any suggestions on how to get these cgi scripts to work properly?

I've tried many different things to get this to work, and I'm happy to provide more detail of any aspect if that will help.


Details:

Mac OS X Server 10.5.8 Xserve 2 x 2.66 Dual-Core Intel Xeon (12 GB) Apache 2.2.13

ruby 1.8.6 (2008-08-11 patchlevel 287) [universal-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 driver: DataDirect SequeLink v5.5 (/Library/ODBC/SequeLink.bundle/Contents/MacOS/ivslk20.dylib)
odbc datasource: FileMaker Server 10 (v10.0.2.206)

) a minimal version of a script (anonymized) that will crash in apache but run successfully from a shell:

#!/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>" 
    }
  }
}

Example of running this from a shell:
gamma% ./minimal.rb (offline mode: enter name=value pairs on standard input) 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%

) typical crash log lines:
Dec 22 14:02:38 gamma ReportCrash[79237]: Formulating crash report for process perl[79236]
Dec 22 14:02:38 gamma ReportCrash[79237]: Saved crashreport to /Library/Logs/CrashReporter/perl_2009-12-22-140237_HTCF.crash using uid: 0 gid: 0, euid: 0 egid: 0
Dec 22 14:03:13 gamma ReportCrash[79256]: Formulating crash report for process perl[79253]
Dec 22 14:03:13 gamma ReportCrash[79256]: Saved crashreport to /Library/Logs/CrashReporter/perl_2009-12-22-140311_HTCF.crash using uid: 0 gid: 0, euid: 0 egid: 0

share|improve this question
add comment

3 Answers

Issues like these are usually due to an environment variable that's set a certain way in the shell, but unset or set differently when the script is run under cgi or cron. Typically they involve an assumption of a path to a file or executable.

share|improve this answer
    
Dennis, thanks for the suggestion. I considered the fact that it was the ODBCINI environment variable, but I tried setting it via the SetEnv apache directive, but it didn't seem to do any good (I did confirm that it was set by printing out the environment in the cgi's). –  Martin Dec 23 '09 at 0:34
add comment

Have you tries defragging the drive?

share|improve this answer
add comment

I had a very similar problem once, with a legacy python web application that used a couple of gnarly cgi scripts. One of them was crashing with weird loader errors in the apache log, such as:

Failed to load libgcc_s.so.1

It turns out that under this particular apache configuration, CGI scripts appeared to have a ulimit of 64MB of memory, and one particular request was using far more than 64MB. Some of the extension modules were linked with libgcc_s for pthreads, so by the time they were imported, the process was already up to the limit and -- smackdown!

I would check the RSS of your script when run manually. If it's a large process, try setting RLimitMEM to something larger, like 128MB or 256MB.

RLimitMEM 128MB
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.