I have an application on heroku which uses mongoid and delayed_job and i have changed the ruby version from 1.9.2 to 1.9.3 I am getting an error
undefined method `match' for nil:NilClass
while I try to save an object to mongoid data base my mongoid.yaml file looks like
production:
sessions:
default:
uri: <%= ENV['MONGOHQ_URL'] %>
options:
skip_version_check: true
safe: true
the trace is here
NoMethodError: undefined method `match' for nil:NilClass
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions/mongo_uri.rb:49:in `initialize'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions/factory.rb:103:in `new'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions/factory.rb:103:in `parse'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions/factory.rb:62:in `create_session'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions/factory.rb:43:in `default'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions.rb:109:in `default'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions.rb:378:in `__session__'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions.rb:213:in `mongo_session'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions.rb:157:in `collection'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/sessions.rb:25:in `collection'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/operations.rb:27:in `collection'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/operations/insert.rb:27:in `block in persist'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/insertion.rb:25:in `block (2 levels) in prepare'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:403:in `_run__4034630009416245289__create__685777988298500290__callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:405:in `__run_callback'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:385:in `_run_create_callbacks'
... 2 levels...
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/insertion.rb:24:in `block in prepare'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:403:in `_run__4034630009416245289__save__685777988298500290__callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:405:in `__run_callback'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:385:in `_run_save_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/callbacks.rb:81:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/callbacks.rb:114:in `run_callbacks'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/insertion.rb:23:in `prepare'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence/operations/insert.rb:26:in `persist'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence.rb:50:in `insert'
from /app/vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.13/lib/mongoid/persistence.rb:79:in `save'
from (irb):2
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/commands/console.rb:47:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/commands/console.rb:8:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/commands.rb:41:in `<top (required)>'
from script/rails:6:in `require'
any one can help me out? thanks in advance
The error is happening because the input parameter to this method https://github.com/mongoid/mongoid/blob/v3.0.13/lib/mongoid/sessions/mongo_uri.rb#L49 is nil.
Looking further back up the call stack to find out where this string comes from (see https://github.com/mongoid/mongoid/blob/v3.0.13/lib/mongoid/sessions/factory.rb#L103) it looks like your uri config param is nil. The uri key is present but empty, so can you check your MONGOHQ_URL configuration param by running heroku config. This should have been set by the MongoHQ addon.
The Ruby 1.9.1 paths in the stack trace are not anything to worry about. See Why Do Heroku Stack Traces indicate Ruby 1.9.1 is in use?
Related
We're working with an older Carrierwave installation and had an issue that caused many of our avatars to be deleted from the S3 bucket but they're still being referenced by Carrierwave. How can I safely clear out these broken instances without breaking our other user's avatars?
Version information:
Ruby 2.1.0
carrierwave-0.5.8
excon-0.32.0
fog-0.7.2
railties-3.2.18
I can't upgrade the gems any further at this point because there are other dependencies that will introduce breaking changes.
I've tried to instance.remove_avatar! functionality but that fails with the following error.
irb(main):041:0> t.remove_avatar!
Digest::Digest is deprecated; use Digest
[excon][WARNING] Invalid Excon request keys: :host
/app/vendor/bundle/ruby/2.1.0/gems/excon-0.32.0/lib/excon/connection.rb:389:in `validate_params'
/app/vendor/bundle/ruby/2.1.0/gems/excon-0.32.0/lib/excon/connection.rb:225:in `request'
/app/vendor/bundle/ruby/2.1.0/gems/fog-0.7.2/lib/fog/core/connection.rb:20:in `request'
/app/vendor/bundle/ruby/2.1.0/gems/fog-0.7.2/lib/fog/storage/aws.rb:323:in `request'
/app/vendor/bundle/ruby/2.1.0/gems/fog-0.7.2/lib/fog/storage/requests/aws/delete_object.rb:20:in `delete_object'
/app/vendor/bundle/ruby/2.1.0/gems/fog-0.7.2/lib/fog/storage/models/aws/file.rb:58:in `destroy'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/storage/fog.rb:178:in `delete'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/uploader/remove.rb:15:in `block in remove!'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/uploader/callbacks.rb:17:in `with_callbacks'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/uploader/remove.rb:14:in `remove!'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/mount.rb:365:in `remove!'
/app/vendor/bundle/ruby/2.1.0/gems/carrierwave-0.5.8/lib/carrierwave/mount.rb:205:in `remove_avatar!'
(irb):41:in `irb_binding'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/workspace.rb:86:in `eval'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/workspace.rb:86:in `evaluate'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/context.rb:380:in `evaluate'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:492:in `block (2 levels) in eval_input'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:624:in `signal_status'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:489:in `block in eval_input'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/ruby-lex.rb:247:in `block (2 levels) in each_top_level_statement'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/ruby-lex.rb:233:in `loop'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/ruby-lex.rb:233:in `block in each_top_level_statement'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/ruby-lex.rb:232:in `catch'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb/ruby-lex.rb:232:in `each_top_level_statement'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:488:in `eval_input'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:397:in `block in start'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:396:in `catch'
/app/vendor/ruby-2.1.0/lib/ruby/2.1.0/irb.rb:396:in `start'
/app/vendor/bundle/ruby/2.1.0/gems/railties-3.2.18/lib/rails/commands/console.rb:47:in `start'
/app/vendor/bundle/ruby/2.1.0/gems/railties-3.2.18/lib/rails/commands/console.rb:8:in `start'
/app/vendor/bundle/ruby/2.1.0/gems/railties-3.2.18/lib/rails/commands.rb:41:in `<top (required)>'
script/rails:6:in `require'
script/rails:6:in `<main>'
=> [:remove_versions!]
I've opened up an issue on Carrierwave's Github tracker as well.
I'm going to close the issue as we were able to work around.
I'd forgotten to mentioned that we are also using the carrierwave-mongoid. Which I think saved our butt.
By setting the instance avatar manually then resaving the model and ignoring the Excon error we forced the models to use their default image.
So in this case, given we have an instance of a model named t.
> t[:avatar] = nil
> t.save rescue nil
This changed the avatar.url to resolve as the default image.
I have two models using the same uploader in a rails project with carrierwave
class Brand < ActiveRecord::Base
mount :avatar, AvatarUploader
end
class Profile < ActiveRecord::Base
mount :avatar, AvatarUploader
end
Then when I try to copy one image to another model
profile.avatar = brand.avatar
profile.save!
it fails with the following stacktrace
undefined method `content_length' for nil:NilClass
usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/storage/fog.rb:238:in `size'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/uploader/proxy.rb:57:in `size'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/sanitized_file.rb:95:in `size'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/sanitized_file.rb:135:in `empty?'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/uploader/cache.rb:119:in `cache!'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/mount.rb:327:in `cache'
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/mount.rb:179:in `avatar='
/usr/lib64/ruby/gems/1.9.1/gems/carrierwave-0.9.0/lib/carrierwave/orm/activerecord.rb:38:in `avatar='
/usr/share/nginx/cranberrychic/releases/20140213171925/app/services/brand_into_user_converter.rb:42:in `copy_avatar'
/usr/share/nginx/cranberrychic/releases/20140213171925/app/services/brand_into_user_converter.rb:13:in `convert'
(irb):64:in `block (2 levels) in irb_binding'
/usr/lib64/ruby/gems/1.9.1/gems/activerecord-3.2.13/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction'
/usr/lib64/ruby/gems/1.9.1/gems/activerecord-3.2.13/lib/active_record/transactions.rb:208:in `transaction'
/usr/lib64/ruby/gems/1.9.1/gems/newrelic_rpm-3.6.0.78/lib/new_relic/agent/method_tracer.rb:486:in `block in transaction_with_trace_ActiveRecord_self_name_transaction'
/usr/lib64/ruby/gems/1.9.1/gems/newrelic_rpm-3.6.0.78/lib/new_relic/agent/method_tracer.rb:235:in `trace_execution_scoped'
/usr/lib64/ruby/gems/1.9.1/gems/newrelic_rpm-3.6.0.78/lib/new_relic/agent/method_tracer.rb:481:in `transaction_with_trace_ActiveRecord_self_name_transaction'
(irb):62:in `block in irb_binding'
/usr/lib64/ruby/gems/1.9.1/gems/activerecord-3.2.13/lib/active_record/relation/delegation.rb:6:in `each'
/usr/lib64/ruby/gems/1.9.1/gems/activerecord-3.2.13/lib/active_record/relation/delegation.rb:6:in `each'
(irb):59:in `irb_binding'
/usr/lib64/ruby/1.9.1/irb/workspace.rb:80:in `eval'
/usr/lib64/ruby/1.9.1/irb/workspace.rb:80:in `evaluate'
/usr/lib64/ruby/1.9.1/irb/context.rb:254:in `evaluate'
/usr/lib64/ruby/1.9.1/irb.rb:159:in `block (2 levels) in eval_input'
/usr/lib64/ruby/1.9.1/irb.rb:273:in `signal_status'
/usr/lib64/ruby/1.9.1/irb.rb:156:in `block in eval_input'
/usr/lib64/ruby/1.9.1/irb/ruby-lex.rb:243:in `block (2 levels) in each_top_level_statement'
/usr/lib64/ruby/1.9.1/irb/ruby-lex.rb:229:in `loop'
/usr/lib64/ruby/1.9.1/irb/ruby-lex.rb:229:in `block in each_top_level_statement'
/usr/lib64/ruby/1.9.1/irb/ruby-lex.rb:228:in `catch'
/usr/lib64/ruby/1.9.1/irb/ruby-lex.rb:228:in `each_top_level_statement'
/usr/lib64/ruby/1.9.1/irb.rb:155:in `eval_input'
/usr/lib64/ruby/1.9.1/irb.rb:70:in `block in start'
/usr/lib64/ruby/1.9.1/irb.rb:69:in `catch'
/usr/lib64/ruby/1.9.1/irb.rb:69:in `start'
/usr/lib64/ruby/gems/1.9.1/gems/railties-3.2.13/lib/rails/commands/console.rb:47:in `start'
/usr/lib64/ruby/gems/1.9.1/gems/railties-3.2.13/lib/rails/commands/console.rb:8:in `start'
/usr/lib64/ruby/gems/1.9.1/gems/railties-3.2.13/lib/rails/commands.rb:41:in `<top (required)>'
script/rails:6:in `require'
script/rails:6:in `<main>'
To me is a bug of carrierwave with fog storage, because in development with the file storage everything works as expected. When I try to copy an image from a model to another in any way possible with carrierwave, it fails with the same error
My carrierwave version is 0.9.0
and rails version is 3.2.13 and ruby 1.9.3-p327
I believe you doing it wrong
profile.avatar = brand.avatar
will not work because profile.avatar= need a file object and brand.avatar don't give you a file object (it return you a uploader i.e avatar object)
I believe your looking for this approach
profile.remote_avatar_url = brand.avatar.url
profile.save!
Considering the brand.avatar.url give you a url from where carrierwave can download the file
More information about remote_{uploader}_url can also be found in Carrierwave Readme
Hope this help
I'm running into an issue using memcached with Rails 3.2.11 and Dalli 2.6.4 on Heroku. Memcached works great in development, but when I push to a staging environment on Heroku I'm running into the following error when I hit the cached page or when I write Rails.cache.clear in the console:
NoMethodError: undefined method `split' for nil:NilClass
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/server.rb:35:in `initialize'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/client.rb:334:in `new'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/client.rb:334:in `block in ring'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/client.rb:326:in `map'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/client.rb:326:in `ring'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/dalli/client.rb:238:in `flush'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/active_support/cache/dalli_store.rb:196:in `block in clear'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/active_support/cache/dalli_store.rb:291:in `block in instrument'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/notifications.rb:125:in `instrument'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/active_support/cache/dalli_store.rb:291:in `instrument'
from /app/vendor/bundle/ruby/1.9.1/gems/dalli-2.6.4/lib/active_support/cache/dalli_store.rb:195:in `clear'
from /app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.11/lib/active_support/cache/strategy/local_cache.rb:88:in `clear'
from (irb):1
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/commands/console.rb:47:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/commands/console.rb:8:in `start'
from /app/vendor/bundle/ruby/1.9.1/gems/railties-3.2.11/lib/rails/commands.rb:41:in `<top (required)>'
from script/rails:6:in `require'
from script/rails:6:in `<main>'
The relevant parts of staging.rb:
config.cache_store = :dalli_store, nil,
{:namespace => 'STAGING', :expires_in => 1.day.to_i, :compress => true }
config.action_dispatch.rack_cache = nil
Any idea what might be causing this issue?
Still not sure what the problem was, but switching to using Dalli 1.1.5 fixed everything.
I'm coming back to an old 2.3.4 Rails app and I'm getting this error and not sure where to start. I also get this when I run a rake task. Here's the trace
NoMethodError: undefined method `name' for "abstract":String
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/rails/gem_dependency.rb:268:in `=='
/Library/Ruby/Site/1.8/rubygems/dependency.rb:217:in `==='
/Library/Ruby/Site/1.8/rubygems/dependency.rb:217:in `matching_specs'
/Library/Ruby/Site/1.8/rubygems/custom_require.rb:36:in `find_all'
/Library/Ruby/Site/1.8/rubygems/specification.rb:410:in `each'
/Library/Ruby/Site/1.8/rubygems/specification.rb:409:in `each'
/Library/Ruby/Site/1.8/rubygems/dependency.rb:216:in `find_all'
/Library/Ruby/Site/1.8/rubygems/dependency.rb:216:in `matching_specs'
/Library/Ruby/Site/1.8/rubygems/dependency.rb:238:in `to_specs'
/Library/Ruby/Site/1.8/rubygems/dependency.rb:256:in `to_spec'
/Library/Ruby/Site/1.8/rubygems.rb:1208:in `gem'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/rails/gem_dependency.rb:73:in `add_load_paths'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:301:in `add_gem_load_paths'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:301:in `each'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:301:in `add_gem_load_paths'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:132:in `process'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `send'
/Library/Ruby/Gems/1.8/gems/rails-2.3.4/lib/initializer.rb:113:in `run'
~/Sites/Volunteer/app/config/environment.rb:7
~/Sites/Volunteer/app/config.ru:1:in `require'
~/Sites/Volunteer/app/config.ru:1
~/Library/Application Support/Pow/Versions/0.3.2/node_modules/nack/lib/nack/builder.rb:4:in `instance_eval'
~/Library/Application Support/Pow/Versions/0.3.2/node_modules/nack/lib/nack/builder.rb:4:in `initialize'
~/Sites/Volunteer/app/config.ru:1:in `new'
~/Sites/Volunteer/app/config.ru:1
Any thoughts on where I should start to fix it? Thanks.
Though it's not the same error, it may be related to an incompatible version of Rubygems. Try downgrading Rubygems or upgrading rails to 2.3.14.
Gem dependency error in rails 2.3.4
As part of my rails project, we are going to use a daemon as a message queue listener to execute commands coming from a Rails RESTful webservice front end.
For ease of prototyping, we are using the Daemons gem to create a very simple daemon. Right now, it's super simple. Here is the code:
require 'rubygems'
require 'daemons'
require File.expand_path('../../config/environment', __FILE__)
Daemons.run_proc('aeon_server') do
loop do
empires = Empire.all
sleep(5)
end
end
Basically, it requires the things for daemons, then requires my Ruby environment, then launches in to the daemon. The daemon simply attempts to query everything from the Empires table. Then it sleeps and does it again.
When it goes to execute 'all', I get the following exception:
C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:109:in `write': closed stream (IOError)
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:109:in `block in flush'
from <internal:prelude>:10:in `synchronize'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:102:in `flush'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:126:in `auto_flush'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:67:in `add'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activesupport-3.0.7/lib/active_support/buffered_logger.rb:78:in `debug'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract_adapter.rb:206:in `rescue in log'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract_adapter.rb:199:in `log'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/sqlite_adapter.rb:135:in `execute'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/sqlite_adapter.rb:284:in `select'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/query_cache.rb:56:in `select_all'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/base.rb:468:in `find_by_sql'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/relation.rb:64:in `to_a'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/relation/finder_methods.rb:143:in `all'
from C:in `all'
from script/aeon_server_control.rb:9:in `block (2 levels) in <main>'
from script/aeon_server_control.rb:7:in `loop'
from script/aeon_server_control.rb:7:in `block in <main>'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/application.rb:249:in `call'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/application.rb:249:in `block in start_proc'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/application.rb:260:in `call'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/application.rb:260:in `start_proc'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/application.rb:293:in `start'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/controller.rb:73:in `run'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons.rb:195:in `block in run_proc'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/cmdline.rb:109:in `call'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons/cmdline.rb:109:in `catch_exceptions'
from C:/Ruby/lib/ruby/gems/1.9.1/gems/daemons-1.1.3/lib/daemons.rb:194:in `run_proc'
from script/aeon_server_control.rb:6:in `<main>'
Any idea why ActiveSupport is throwing this exception? Are there additional steps I need to "bootstrap" my rails environment in to the daemon, beyond just requiring the environment?
There're some intricacies with regard to file descriptors when the process is forked/spawned/whatever-it-is-called-on-windows.
Try to reinstantiate a logger after you do Daemons.run_proc('aeon_server') with Rails.logger = ActiveSupport::BufferedLogger.new('/path/to/log')