I originally posted a question relating to this problem on serverfault.com: https://serverfault.com/questions/152587/apache-mod-proxy-to-another-server
I have since realized that this is not an issue with my server setup, but my rails application. I have set this application up server-wise the exact same as another functioning rails app I have running on the same server. When I start the server my mongrel.log looks like this:
** Daemonized, any open files are closed. Look at /var/www/osuwebdev/tmp/pids/mongrel.pid and log/mongrel.log for info.
** Starting Mongrel listening at 0.0.0.0:8080
** Starting Rails with production environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
** Rails signals registered. HUP => reload (without restart). It might not work well.
** Mongrel 1.1.5 available at 0.0.0.0:8080
** Writing PID file to /var/www/osuwebdev/tmp/pids/mongrel.pid
When I load a page this pops up in the log:
Wed Jun 30 19:46:10 +0000 2010: Error calling Dispatcher.dispatch #<NoMethodError: undefined method `[]' for nil:NilClass>
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/cgi.rb:108:in `send_cookies'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/cgi.rb:136:in `out'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/http_response.rb:65:in `start'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/cgi.rb:135:in `out'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/rails.rb:81:in `process'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:159:in `process_client'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `each'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:158:in `process_client'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `initialize'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `new'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:285:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `initialize'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `new'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel.rb:268:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:282:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `each'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/configurator.rb:281:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:128:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/../lib/mongrel/command.rb:212:in `run'
/var/lib/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails:281
/usr/local/bin/mongrel_rails:19:in `load'
/usr/local/bin/mongrel_rails:19
I cannot figure out what is different about this app that may cause this issue.
I believe this is a weird combination of bugs in Rack, Mongrel, and Rails.
Save this ruby code in your app to config/mongrel.rb: http://gist.github.com/471663
In your config/environment.rb, at the very end of the file add:
require File.join(File.dirname(File.expand_path(FILE)), 'mongrel')
In that same file add this line in the Rails::initializer.run block:
config.gem "mongrel"
Longer explanation of the problem here: https://rails.lighthouseapp.com/projects/8994/tickets/4690-mongrel-doesnt-work-with-rails-238
This has definitely worked for a Rails 2.3.8 app, though I patched it slightly differently than described above.
Do you still see the problem on subsequent GET requests? I had a similar problem where my Rails app would run fine under WEBrick but not under Mongrel but found somewhere on the internets (here's a link that shows a similar version of the problem) that older versions of Mongrel mishandle the first request to the page but handle subsequent requests ok.
The workaround we put in was that whenever we started the app, we'd have curl perform a GET on the app to 'prime' Mongrel.
This is usually a fail reading a yaml file for config. It has set up a config object to get values from and the entry in the yaml file for your environment isn't there so the object is nil.
Are you running any gems that have a yaml file that maybe isn't set up for development?
I don't know why going back to 2.3.5 would help - it might be that it loads things in a different order and the config information is available.
Related
I'm trying to run dokku on DigitalOcean with a sample rails app, but when I deploy, I get this error:
Puma starting in single mode...
* Version 3.12.1 (ruby 2.6.3-p62), codename: Llamas in Pajamas
* Min threads: 5, max threads: 5
* Environment: production
* Listening on tcp://0.0.0.0:5000
bundler: failed to load command: rackup (/app/vendor/bundle/ruby/2.6.0/bin/rackup)
Errno::ENOENT: No such file or directory # rb_sysopen - tmp/pids/server.pid
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/launcher.rb:133:in `initialize'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/launcher.rb:133:in `open'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/launcher.rb:133:in `write_pid'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/launcher.rb:106:in `write_state'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/single.rb:103:in `run'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/puma/launcher.rb:186:in `run'
/app/vendor/bundle/ruby/2.6.0/gems/puma-3.12.1/lib/rack/handler/puma.rb:73:in `run'
/app/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/server.rb:297:in `start'
/app/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/lib/rack/server.rb:148:in `start'
/app/vendor/bundle/ruby/2.6.0/gems/rack-2.0.7/bin/rackup:4:in `<top (required)>'
/app/vendor/bundle/ruby/2.6.0/bin/rackup:23:in `load'
/app/vendor/bundle/ruby/2.6.0/bin/rackup:23:in `<top (required)>'
I've looked through other support sites for a similar error - but it looks like the web app container starts then immediately stops.
I can see my database container running, and I see a container with dokkku/myapp:latest - and it's never up for more than a few seconds.
Anyone have an idea why?
Rails 6 added a line to config/puma.rb that specifies the location of the pidfile (line 20 by default, at the time of my writing this), with the default value as follows:
pidfile ENV.fetch("PIDFILE") { "tmp/pids/server.pid" }
I ran into the same problem you mentioned, and addressed it by changing that line to
pidfile ENV.fetch("PIDFILE") { "server.pid" }
Removing the tmp dir from both .gitignore and .dockerignore (in my case, since my app is Dockerized) also worked, but having tmp dirs in git and on my production containers smelled funny, so I opted for the aforementioned approach.
Either way, I'm glad you got it working! ... hope this helps
PS - you may want to consider selecting one of these answers as correct (even if it's an answer you provided) Happy coding!
tmp/pids/server.pid is the file Rails uses to check if it is already running, and to check what process ID it is running with.
IIRC with Dokku, there is a user called dokku that all Dokku processes run under - make sure that user (or whichever user Dokku/the Rails app is running under), has read/write permission on that directory.
Alternatively, you may be able to just call touch tmp/pids/server.pid to create the file so that Rails can use it.
Not sure why this is an issue - but my .gitignore file (a default, I think) kept the /tmp folder, but ignored contents, so there wasn't a /tmp/pids in the repo, and there probably wasn't on the web container.
I forced the /tmp/pids folder into the repo... and now it works!
I'm trying to run Rails on JRuby 1.7.3 in userspace on Solaris and I get this error when running rake db:create.
-bash-3.2$ rake db:create
rake aborted!
undefined method `error' for #<ActiveRecord::JDBCError:0x109d7b8>
org/jruby/RubyArray.java:1613:in `each'
org/jruby/RubyProc.java:249:in `call'
org/jruby/RubyArray.java:1613:in `each'
org/jruby/RubyArray.java:1613:in `each'
org/jruby/RubyKernel.java:1046:in `load'
Tasks: TOP => db:create
(See full trace by running task with --trace)
I have looked at the JRuby source for this line, but I'm pretty far out of my depth on this and I'm not sure what's going on. Has anyone seen this before?
I haven't run on that kind of error before, but just to double-check .. have you used jruby specific gem for making a connection to databases:
https://github.com/jruby/activerecord-jdbc-adapter
If not, try using that instead the ones you have been using so far for "regular" ruby
I just run into this error. It seems like a bug in Rails. Your idea of inspecting the source for that line was a good one. I went there and changed $stdout.print error.error for just $stdout.print error because the error method didn't seem defined.
That revealed the actual error:
#<ActiveRecord::JDBCError: Access denied for user 'root'#'localhost' (using password: YES)>
In my case, I was mispelling the username key in the config/database.yml file, so it would assume the root user, but the password would be wrong.
I am getting a really strange error from ActiveResource. I have a method that calls another system to get a list of products. The list is quite large and takes about 3 minutes to generate and transfer. Since this is really only a once a day kinda thing I built a rake task to run it. In production whenever I run the rake task it fails with a 500 error. Here is some sample output
$ time RAILS_ENV=production rake api:sync
rake aborted!
Failed with 500 Internal Server Error
(See full trace by running task with --trace)
real 2m1.753s
user 0m1.188s
sys 0m0.188s
Then I tried to use script runner:
$ RAILS_ENV=production script/runner 'Product.synchronize!(ProductManager::Product.find_valid_products)'
/var/www/apps/api/releases/20091202203413/vendor/rails/railties/lib/commands/runner.rb:48: Failed with 500 Internal Server Error (ActiveResource::ServerError)
from /usr/local/lib/ruby/1.8/net/protocol.rb:133:in `rbuf_fill'
from /usr/local/lib/ruby/1.8/timeout.rb:62:in `timeout'
from /usr/local/lib/ruby/1.8/timeout.rb:93:in `timeout'
from /usr/local/lib/ruby/1.8/net/protocol.rb:132:in `rbuf_fill'
from /usr/local/lib/ruby/1.8/net/protocol.rb:116:in `readuntil'
from /usr/local/lib/ruby/1.8/net/protocol.rb:126:in `readline'
from /usr/local/lib/ruby/1.8/net/http.rb:2020:in `read_status_line'
from /usr/local/lib/ruby/1.8/net/http.rb:2009:in `read_new'
... 17 levels...
from /var/www/apps/api/releases/20091202203413/vendor/rails/railties/lib/commands/runner.rb:48
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
from script/runner:3
However if I jump into the console to run it, everything is fine:
$ script/console production
Loading production environment (Rails 2.3.5)
>> Product.synchronize!(ProductManager::Product.find_valid_products); nil # prevent dump to console
=> nil
>>
I suspected it was a timeout, so I set the timeout value to 5 minutes on the ProductManager::Product class, but that had no effect. The interesting thing is that when I run via rake or script/runner the error happens occurs at 2 minutes and 1 second without fail. In development and staging there is no issue. Does production of ActiveResource have some kind of hidden 2 minute override I can't find?
In case you didn't get it from the traces, we are using Rails 2.3.5 frozen into the application. Thanks for you help
Peer
Turns out it was an Apache setting. The RequestTimeout in the httpd.conf file was 120 seconds. Once we upped that everything was fine.
I get the following error when I run my task via DelayedJob:
closed stream
/usr/lib/ruby/1.8/drb/drb.rb:961:in `select'
/usr/lib/ruby/1.8/drb/drb.rb:961:in `alive?'
/usr/lib/ruby/1.8/drb/drb.rb:1211:in `alive?'
/usr/lib/ruby/1.8/drb/drb.rb:1168:in `open'
/usr/lib/ruby/1.8/drb/drb.rb:1166:in `each'
/usr/lib/ruby/1.8/drb/drb.rb:1166:in `open'
/usr/lib/ruby/1.8/drb/drb.rb:1163:in `synchronize'
/usr/lib/ruby/1.8/drb/drb.rb:1163:in `open'
/usr/lib/ruby/1.8/drb/drb.rb:1092:in `method_missing'
/usr/lib/ruby/1.8/drb/drb.rb:1110:in `with_friend'
/usr/lib/ruby/1.8/drb/drb.rb:1091:in `method_missing'
/usr/lib/ruby/gems/1.8/gems/acts_as_ferret-0.4.3/lib/remote_index.rb:31:in `<<'
/usr/lib/ruby/gems/1.8/gems/acts_as_ferret-0.4.3/lib/instance_methods.rb:90:in `ferret_update'
...
From the error its obvious that delayed_job could not find the ferret_server. However, when I run this SAME task from console in production mode, it works fine. Any ideas how I can ensure that delayed_job has:
really loaded the production environment. I set RAILS['ENV]] = 'production' in the script/delayed_job to ensure this. (I guess this should be good)
got ferret configured via models?
This happened to me too. You need to disable ferret from indexing during the running of the delayed job.
In your worker definition (something like RAILS_ROOT/lib/worker.rb), and given a model called Post, you should include a line like this:
class Worker < Struct.new(:stuff)
def perform
Post.disable_ferret
<do some stuff>
.
.
.
end
end
Why do I get following error when trying to start a ruby on rails application with mongrel_rails start?
C:\RailsTest\cookbook2>mongrel_rails start
** WARNING: Win32 does not support daemon mode.
** Daemonized, any open files are closed. Look at log/mongrel.pid and log/mongr
el.log for info.
** Starting Mongrel listening at 0.0.0.0:3000
c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../lib/mongrel/t
cphack.rb:12:in `initialize_without_backlog': Only one usage of each socket addr
ess (protocol/network address/port) is normally permitted. - bind(2) (Errno::EAD
DRINUSE)
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/tcphack.rb:12:in `initialize'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel.rb:93:in `new'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel.rb:93:in `initialize'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/configurator.rb:139:in `new'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/configurator.rb:139:in `listener'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mon
grel_rails:99:in `cloaker_'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/configurator.rb:50:in `call'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/configurator.rb:50:in `initialize'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mon
grel_rails:84:in `new'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mon
grel_rails:84:in `run'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../
lib/mongrel/command.rb:212:in `run'
from c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mon
grel_rails:281
from c:/ruby/bin/mongrel_rails:19:in `load'
from c:/ruby/bin/mongrel_rails:19
You already have a process listening on port 3000 (the default port for mongrel).
Try:
mongrel_rails start -p 3001
and see whether you get a similar error.
If you're trying to install more than one Rails app, you need to assign each mongrel to a separate port and edit you apache conf accordingly.
If you not trying to do that, the most direct way of killing all mongrels is to open windows task manager and kill all the 'ruby' processes.
Note that if you have mongrel installed as a service that starts automatically
mongrel_rails install::service ...
...the ruby process will regenerate automatically. In that case, you'll have to edit the process properties through the windows services panel. Let me know if you need more info.
I don't use mongrel on windows myself, but I guess that error is the equivalent of Linux' "port in use" error. Are you trying to bind the server to a port where something else is already listening?
On Windows, I found two possible ways for fixing this issue:
Work around: Start the mongrel web server in another port
Solution: Find the ruby.exe process in your task manager and finish it