Status: 500 Internal Server Error - A session_key is require


#1

Hi,

Anyone seen this error / have any suggestions here?

I basically did a “cap deploy” to dreamhost but I’m now getting this in
the
“production.log” when trying to run up the application. The key things
I
changed in the deployment is that I:

a) When to rails v1.2.3 (well to revision 6419 really for completeness -
which I looked up to be v1.2.3)
b) I implemented the deployment technique from Mike C. at the bottom
section (“The Cadillac Approach”) of
http://clarkware.com/cgi/blosxom/2007/01/18#ManagingVersionsWithCap,
i.e.

  • checks out rails (rev 6419) to a shared area
  • then symlinks the app /vendor/rails directory to this area
  • basically allows capistrano to be run to update your application but
    without having to put rails into the project to minimise checkout time

Any ideas?

(actually I’m not exactly sure with this approach what setting I should
use
in environment.rb for RAILS_GEM_VERSION - I’ve tried both commenting it
out
and setting it to ‘1.2.2’ but I get the below error in both cases)

DISPATCHER FAILSAFE RESPONSE (has cgi) Tue Apr 03 12:33:37 -0700 2007
Status: 500 Internal Server Error
A session_key is required to write a cookie containing the session
data.
Use config.action_controller.session = { :session_key =>
“_myapp_session”,
:secret => “some secret phrase” } in config/environment.rb

…/config/…/vendor/rails/actionpack/lib/action_controller/session/cookie_store.rb:49:in
initialize' /usr/lib/ruby/1.8/cgi/session.rb:273:innew’
/usr/lib/ruby/1.8/cgi/session.rb:273:in
`initialize_without_cgi_reader’

…/config/…/vendor/rails/actionpack/lib/action_controller/cgi_ext/session_performance_fix.rb:33:in
`initialize’

…/config/…/vendor/rails/actionpack/lib/action_controller/cgi_process.rb:124:in
`new’

…/config/…/vendor/rails/actionpack/lib/action_controller/cgi_process.rb:124:in
`session’

…/config/…/vendor/rails/actionpack/lib/action_controller/cgi_process.rb:156:in
`stale_session_check!’

…/config/…/vendor/rails/actionpack/lib/action_controller/cgi_process.rb:111:in
`session’

…/config/…/vendor/rails/actionpack/lib/action_controller/base.rb:1097:in
`assign_shortcuts_without_flash’

…/config/…/vendor/rails/actionpack/lib/action_controller/flash.rb:174:in
`assign_shortcuts’

…/config/…/vendor/rails/actionpack/lib/action_controller/base.rb:467:in
`process_without_filters’

…/config/…/vendor/rails/actionpack/lib/action_controller/filters.rb:652:in
`process_without_session_management_support’

…/config/…/vendor/rails/actionpack/lib/action_controller/session_management.rb:122:in
`process’

…/config/…/vendor/rails/actionpack/lib/action_controller/base.rb:326:in
process' ../config/../vendor/rails/railties/lib/dispatcher.rb:39:indispatch’
…/config/…/vendor/rails/railties/lib/fcgi_handler.rb:168:in
process_request' ../config/../vendor/rails/railties/lib/fcgi_handler.rb:143:inprocess_each_request!’
…/config/…/vendor/rails/railties/lib/fcgi_handler.rb:109:in
with_signal_handler' ../config/../vendor/rails/railties/lib/fcgi_handler.rb:142:inprocess_each_request!’
/usr/lib/ruby/1.8/fcgi.rb:600:in each_cgi' /usr/lib/ruby/1.8/fcgi.rb:597:ineach’
/usr/lib/ruby/1.8/fcgi.rb:597:in each_cgi' ../config/../vendor/rails/railties/lib/fcgi_handler.rb:141:inprocess_each_request!’
…/config/…/vendor/rails/railties/lib/fcgi_handler.rb:55:in
process!' ../config/../vendor/rails/railties/lib/fcgi_handler.rb:25:inprocess!’
dispatch.fcgi:24

Tks
Greg


#2

PS. I have confirmed that using this approach (“The Cadillac Approach”)
it
has worked with rails 1.2.1 and 1.2.2. It is just 1.2.3 that is giving
this
issue. Any ideas?


#3

Edge Rails is trying out a new cookie-based session. You have to set
some
variables in environment.rb. Personally, I don’t understand why the
environment.rb in Edge doesn’t come with this setting already in it but
whatever. You can read more about it here…

http://ryandaigle.com/articles/2007/2/21/what-s-new-in-edge-rails-cookie-based-sessions

Hope that helps.

RSL


#4

Thanks - The curiosity I have is that I was checking out based on the
“6419”
tag, whic is (my understanding), is the Rails 1.2.3 release. So I’m
wondering if this latest release of rails v1.2.3 has an issue? Perhaps
I
should post on the dev/core mailing list?


#5

On 4/4/07, Greg H. removed_email_address@domain.invalid wrote:

Thanks - The curiosity I have is that I was checking out based on the “6419”
tag, whic is (my understanding), is the Rails 1.2.3 release. So I’m
wondering if this latest release of rails v1.2.3 has an issue? Perhaps I
should post on the dev/core mailing list?

Greg, you’re on revision 6419 of Rails trunk. You want the 1-2-stable
branch instead.

jeremy


#6

oh, I wasn’t sure how to look up the SVN revision number for the
1.2.3release and someone suggested to reference it via
http://dev.rubyonrails.org/browser/tags this link. The deployment
technique from Mike C. at the bottom section (“The Cadillac
Approach”) of
http://clarkware.com/cgi/blosxom/2007/01/18#ManagingVersionsWithCap that
I’m
following seems to require you put in such a SVN revision number.

Any suggestions how I should reference the stable release via an SVN
revision number Jeremy?

thanks
Greg


#7

On 4/4/07, Greg H. removed_email_address@domain.invalid wrote:

oh, I wasn’t sure how to look up the SVN revision number for the 1.2.3
release and someone suggested to reference it via
http://dev.rubyonrails.org/browser/tags this link. The
deployment technique from Mike C. at the bottom section (“The Cadillac
Approach”) of
http://clarkware.com/cgi/blosxom/2007/01/18#ManagingVersionsWithCap
that I’m following seems to require you put in such a SVN revision number.

Any suggestions how I should reference the stable release via an SVN
revision number Jeremy?

Each release is tagged; you don’t have to track revisions.

http://svn.rubyonrails.org/rails/tags/rel_1-2-3 is the 1.2.3 release.

jeremy


#8

PS. Perhaps there was a 1.2.2 to 1.2.3 upgrade script/command I was
supposed to run but didn’t on my application? Anyone know whether there
was
a requirement to do this?