Forum: Ruby debugging a cgi

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
maggelet (Guest)
on 2005-11-22 21:27
(Received via mailing list)
Hi,
Is there a good way to get more information about what went wrong in a
ruby cgi script than just a 500 error page?
I know I could run it from a shell but this isn't always an option.
I'm running as cgi on apache.
Thanks,
- Mark
hhausman (Guest)
on 2005-11-22 21:55
(Received via mailing list)
So far, what I've found is that it's pretty much all about running it
from the shell. It will be recognized by the interpreter as a cgi
script and you will be prompted for name=value pairs for the query
string. Works supprisingly well.

Of course, if theres something better I'd love to know too.

-Harold
detlef.reichl (Guest)
on 2005-11-22 21:59
(Received via mailing list)
On Mi, 2005-11-23 at 04:27 +0900, mark wrote:
> Hi,
> Is there a good way to get more information about what went wrong in a
> ruby cgi script than just a 500 error page?

Ehm...

take a look to the webserver logs?

/var/log/apache(2)/error.log

Cheers
detlef
maggelet (Guest)
on 2005-11-22 23:04
(Received via mailing list)
Thanks for the suggestions, however running from the shell and viewing
logs are not usually available in budget hosting packages. I found a
way to do what I want with mod_ruby by setting up a custom 500 page and
putting:

r = Apache.request
rp = r.prev
backtrace_id = nil
puts rp.error_message.to_s

however this only works for mod_ruby.
Any tips much appreciated
bob_showalter (Guest)
on 2005-11-22 23:28
(Received via mailing list)
mark wrote:
> Thanks for the suggestions, however running from the shell and viewing
> logs are not usually available in budget hosting packages.

I'm not an expert on this, but why not wrap your entire script in
something like this:

   begin

      ...your script here...

   rescue Exception
      print "Content-Type: text/plain\r\n\r\n"
      puts $!.inspect, $!.backtrace
   end

That should put out a valid response for any uncaught exception and show
the error at the client.
maggelet (Guest)
on 2005-11-23 20:28
(Received via mailing list)
Thanks for the suggestion,
but this will only help in cases where an Exception is thrown.
bob_showalter (Guest)
on 2005-11-23 20:48
(Received via mailing list)
mark wrote:
> Thanks for the suggestion,
> but this will only help in cases where an Exception is thrown.
>

What could cause a 500 response?

1) Script won't pass 'ruby -c'. You can check this on another system.
2) Script emits a malformed MIME header. This should be easy to check.
3) Script raises an exception.

Is there something else I'm not seeing?
maggelet (Guest)
on 2005-11-23 22:04
(Received via mailing list)
Hi Bob,
The idea is to make debugging cgi's easier. Yes I can check it on
another system, but it's a hassle.

In addition to your suggestion here's what I came up with so far:
I made a custom 500 error document called /500.rb and put:
----------------
#!/usr/local/bin/ruby
print "Content-Type: text/plain\n\n"
unless ENV["REQUEST_URI"] == "/500.rb" # to avoid recursion
	script = ENV["DOCUMENT_ROOT"] + ENV["REQUEST_URI"]
	puts `/usr/local/bin/ruby #{script} 2>&1`
end
----------------
this doesn't deal with the get and post vars but I'll fix that later.
It would be nice if there is a way to get ruby to bomb to the 500 page
on exceptions so that I don't need the 'rescue' on every page. right
now the exception just causes ruby to quit without going to the 500
page

Thanks for the input,
- Mark
This topic is locked and can not be replied to.