Forum: Ruby on Rails App running fine on Webrick, ActiveRecord::ConnectionNotEsta

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.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-01-28 01:19
(Received via mailing list)
My app runs fine on webrick, but I get a
ActiveRecord::ConnectionNotEstablished when I try to run it on
lighttpd.  Here's the app's lighttpd config:

$HTTP["host"] =~ "(www\.)?mysite\.com" {
  server.document-root = "/home/pergesuteore/public/"
  server.error-handler-404 = "/dispatch.fcgi"

  fastcgi.server = ( ".fcgi" =>
    ( "localhost" =>
      (
        "socket" => "/var/lighttpd/teore.socket",
        "bin-path" => "/home/pergesu/teore/public/dispatch.fcgi",
        "bin-environment" => ( "RAILS_ENV" => "production" ),
        "min-procs" => 5,
        "max-procs" => 5,
        "idle-timeout" => 60
      )
    )
  )
}

One thing I've noticed is that the socket files are named
teore.socket-0=, teore.socket-1=, etc, whereas on my dev machine
they're just teore.socket-0.  Not sure if perhaps the = is a file type
designator on linux or something, but that's my first suspicion as to
what the problem is.  Anyone have a clue what's going on?  Actually
now I'm pretty sure it's just some designator thing.

Also, when I do script/console it connects fine, so I'm pretty sure
the ConnectionNotEstablished error is something to do with the fastcgi
connection.


Here's the full error

/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:111:in
`retrieve_connection'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/connection_adapters/abstract/connection_specification.rb:20:in
`connection'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/base.rb:734:in
`columns'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/base.rb:1663:in
`attributes_from_column_definition'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/base.rb:1185:in
`initialize_without_callbacks'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.13.2/lib/active_record/callbacks.rb:236:in
`initialize'
#{RAILS_ROOT}/app/controllers/user_controller.rb:67:in `generate_blank'
#{RAILS_ROOT}/app/controllers/user_controller.rb:3:in `login'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/base.rb:853:in
`perform_action_without_filters'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/filters.rb:332:in
`perform_action_without_benchmark'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:69:in
`perform_action_without_rescue'
/usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:69:in
`perform_action_without_rescue'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/rescue.rb:82:in
`perform_action'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/base.rb:369:in
`process_without_session_management_support'
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/session_management.rb:116:in
`process'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:38:in
`dispatch'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:141:in
`process_request'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:53:in
`process!'
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:600:in `each_cgi'
/usr/local/lib/ruby/site_ruby/1.8/fcgi.rb:597:in `each_cgi'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in
`process!'
/usr/local/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:22:in
`process!'
/home/kebp/teore/public/dispatch.fcgi:24
132a94ca65959bda6c74fae54bff2425?d=identicon&s=25 Ezra Zygmuntowicz (Guest)
on 2006-01-28 01:31
(Received via mailing list)
Pat-

	I am not sure what your current problem is. I have never ever seen a
socket get named with an = sign at the end when you didn't set it
that way explicitly.

	One thing I thought I might mention is that you are setting % fcgi
processes up. I don't know how much traffic the site you are setting
up will be serving but let me tell you that the http://
yakimaherald.com runs on 5 fcgi listeners and it serves 70.000+ page
views a day and it could probably do that on less fcgi's. I would
recommend that you use maybe 2 fcgi's until you can tell that they
are being maxed out. What will happen is that if you spawn 5
listeners and don't have a ton of traffic, only one of them will get
used and the others will sit there idle taking up memory and
resources that you don't need to use unless necessary.

	Just fyi

Cheers-
-Ezra

On Jan 27, 2006, at 4:18 PM, Pat Maddox wrote:

>       (
>
>
> `connection'
> active_record/callbacks.rb:236:in
> /usr/local/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/
> action_controller/base.rb:369:in
> 53:in
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
ezra@yakima-herald.com
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-01-28 01:40
(Received via mailing list)
Hey I figured it out..I had killed the lighty process with a -9, and
the sockets obviously weren't removed wtih it.  So the next time I
tried to start it up, I guess it just used those sockets and couldn't
work.  Removed the sockets and restarted, it was fine.

Now I'm having some strange permission error.  I set lighttpd to run
as www:nobody, and my log files are set chmod 666.  However I'm
getting:

Rails Error: Unable to access log file. Please ensure that
/home/pergesu/teore/public/../config/../log/production.log exists and
is chmod 0666. The log level has been raised to WARN and the output
directed to STDERR until the problem is fixed.  production.log is
definitely 666 though.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-01-28 02:25
(Received via mailing list)
Apparently the log dir needs to be 777.  All good now.
This topic is locked and can not be replied to.