My Ruby on Rails app was running smoothly until yesterday.
When ever I try to open my Heroku App it gives me a "Application Error" message and when I check my logs I get this message below.
[36m2013-09-10T17:42:34.393159+00:00 app[web.1]: [0m Connecting to database
specified by DATABASE_URL
[36m2013-09-10T17:42:34.846457+00:00 app[web.1]: [0m Exiting
[36m2013-09-10T17:42:34.849786+00:00 app[web.1]: [0m /app/vendor/bundle/ruby/2.
0.0/gems/devise-3.1.0/lib/devise/rails/routes.rb:440:in `raise_no_secret_key':
Devise.secret_key was not set. Please add the following to your Devise
initializer: (RuntimeError)
Has anyone encountered this? What does the error mean?
A discussion about that error here:
https://github.com/plataformatec/devise/issues/2554
Follow the error log instructions in your post. Add the following to your Devise initializer:
config.secret_key = '-- secret key --'
Related
We recently started having trouble with chef-client dying in the middle of a run after taking a lot more time stuck on various parts of the run-list that normally proceeded much quicker. I've been on my home wifi and my colleague has been on the work wifi, which has been having some connectivity problems of its own.
If your ssh connection gets interrupted to a machine while chef-client is running, does that crash the run in seemingly inexplicable ways? I am using PutTY to connect from my Win7 and my colleague is using the Apple Terminal App.
All the machines we've been running this on are Ubuntu 12.04 (in EC2) and have plenty of disk space left over - they're only utilizing ~1GB with ~5GB free.
Here is the output of the log from /var/log/chef/client.log (set with the log_location directive in /etc/chef/client.rb as described here).
[2014-01-08T00:27:07+00:00] WARN: Nodejs user is nodejs
[2014-01-08T00:27:07+00:00] WARN: Cloning resource attributes for group[nodejs] from prior resource (CHEF-3694)
[2014-01-08T00:27:07+00:00] WARN: Previous group[nodejs]: /var/chef/cache/cookbooks/nodejs/recipes/default.rb:26:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Current group[nodejs]: /var/chef/cache/cookbooks/spicoli-app/recipes/default.rb:38:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Cloning resource attributes for user[nodejs] from prior resource (CHEF-3694)
[2014-01-08T00:27:07+00:00] WARN: Previous user[nodejs]: /var/chef/cache/cookbooks/nodejs/recipes/default.rb:34:in `from_file'
[2014-01-08T00:27:07+00:00] WARN: Current user[nodejs]: /var/chef/cache/cookbooks/spicoli-app/recipes/default.rb:46:in `from_file'
[2014-01-08T00:27:30+00:00] WARN: Environment is _default
[2014-01-08T00:27:30+00:00] WARN: Nodejs user is nodejs
[2014-01-08T02:04:54+00:00] ERROR: Running exception handlers
[2014-01-08T02:04:54+00:00] ERROR: Exception handlers complete
[2014-01-08T02:04:54+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-01-08T02:04:55+00:00] ERROR: Input/output error - <STDOUT>
[2014-01-08T02:04:57+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
And the error stacktrace just has this:
Generated at 2014-01-08 02:04:54 +0000
Errno::EIO: Input/output error - <STDOUT>
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `write'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `puts'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:91:in `puts'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:61:in `display_section'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:44:in `block (2 levels) in display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:43:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:43:in `block in display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:42:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/error_descriptor.rb:42:in `display'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:130:in `display_error'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/base.rb:161:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/formatters/doc.rb:159:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `block in resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/event_dispatch/dispatcher.rb:29:in `resource_failed'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource.rb:637:in `rescue in run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource.rb:643:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/resource_collection.rb:96:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:433:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:500:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:199:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:193:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/client.rb:193:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application.rb:208:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:312:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:304:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application/client.rb:304:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.8.0/bin/chef-client:26:in `<top (required)>'
/usr/bin/chef-client:23:in `load'
/usr/bin/chef-client:23:in `<main>'
Which is a really generic error! But it does seem to indicate an interruption to STDOUT output, which kind of makes sense with a client disconnection.
Edit: As requested, here are the contents of the client.rb file (names obfuscated, naturally.)
$ cat /etc/chef/client.rb
log_level :auto
log_location "/var/log/chef/client.log"
chef_server_url "https://api.opscode.com/organizations/myapp"
validation_client_name "my-validator"
node_name "my-app-node"
Edit 2: Attempt using sudo su -s /bin/bash root -c "screen chef-client"
Screen terminated while I was at lunch and recorded a timeout on the ShellOut command for npm install. This was after chef-client was sitting stuck on this operation for over an hour.
[2014-01-09T16:39:07+00:00] WARN: Environment is _default
[2014-01-09T16:39:07+00:00] WARN: Nodejs user is nodejs
[2014-01-09T18:16:28+00:00] ERROR: Running exception handlers
[2014-01-09T18:16:28+00:00] ERROR: Exception handlers complete
[2014-01-09T18:16:28+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-01-09T18:16:31+00:00] ERROR: execute[npm-install-app] (spicoli-app::default line 110) had an error: Mixlib::ShellOut::CommandTimeout: command timed out:
---- Begin output of npm --registry http://my.npm.repo.amazonaws.com:5984/registry/_design/app/_rewrite install --cache /home/nodejs/.npm --tmp /home/nodejs/tmp
--- snip: install messages from npm ---
[2014-01-09T18:16:33+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
This is a totally different error than before. The stacktrace.out file also explicitly mentions ShellOut, so it is entirely different as well. Most oddly, when I run the same npm command from the command line, in finishes in under a minute.
So I'm not sure there is a way to further diagnose the previous failure, but I would welcome other suggestions. For input on this new failure, I asked this followup question.
If your ssh connection gets interrupted to a machine while chef-client is running, does that crash the run in seemingly inexplicable ways?
Well, the stacktrace seems to imply that something like that is happening. The message says "Errno::EIO: Input/output error - <STDOUT>" which is consistent with what I'd expect to see if STDOUT was going over an SSH channel that had been closed.
I suggest 2 things:
Run chef-client with all console output redirected to a file; e.g. add > /tmp/log 2>&1 to the end of the command. (The redirection needs to happen on the remote machine.)
Add -l debug to the command to increase the level of logging, as covered in Opscode's technical FAQ. This could reveal clues that are currently being hidden.
Looking at your second update, this has the hallmarks of some kind of firewall or network related problem.
Following Michael Hartl's ROR tutorial getting this weird error after following the instructions in section 3.2 Tests.
I run the command: bundle exec rspec spec/requests/static_pages_spec.rb
I get the error:
bundle exec rspec spec/requests/static_pages_spec.rb
/Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/configuration.rb:780:in load': no such file to load -- /Users/name/Desktop/ROR/sample-app/spec/requests/spec/requests/static_pages_spec.rb (LoadError)
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/configuration.rb:780:inblock in load_spec_files'
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/configuration.rb:780:in map'
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/configuration.rb:780:inload_spec_files'
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/command_line.rb:22:in run'
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/runner.rb:69:inrun'
from /Users/name/.rvm/gems/ruby-1.9.2-p320/gems/rspec-core-2.11.1/lib/rspec/core/runner.rb:8:in `block in autorun'
any help would be appreciated
The error message indicates that it's looking for the file in /Users/name/Desktop/ROR/sample-app/*spec/requests/spec/requests/*static_pages_spec.rb
Are you already in the spec/requests/ directory when trying to run this command? The assumption is that you're in the project's home directory; if you're already in spec/requests/, you can just run:
bundle exec rspec static_pages_spec.rb
UPDATE: My issue is definitely related to this one - it's an issue with ActiveRecord. Still not solved.
I'm trying to get a test to pass in rspec and can't figure out what's going wrong... Here's what I'm getting:
Running: spec/models/user_spec.rb
.
.
.
........F
Failures:
1) User when email address is already taken
Failure/Error: user_with_same_email.save
ActiveRecord::StatementInvalid:
SQLite3::SQLException: near "SAVEPOINT":
syntax error: SAVEPOINT active_record_1
# ./spec/models/user_spec.rb:64:in `block (3 levels) in <top (required)>'
Finished in 0.22908 seconds
9 examples, 1 failure
Here's the related line in my test:
user_with_same_email.save
it breaks when trying to write to the db. Development is fine - no issues.
Thanks
The issue was an old version of sqlite. I installed Homebrew and ran brew install sqlite3
A number of errors came up due to files that already existed. I just renamed them *.old and ran brew link sqlite3. Problem solved!
I'm using the Spawn gem in a rails 3 app - it's the rails3-adapted fork at https://github.com/rfc2822/spawn
My app is deployed on heroku, and when i tried to spawn i get this failure:
app[web.1]: ### ../controllers/messages_controller.rb:10:in `create_message': About to spawn
app[web.1]: spawn> parent PID = 1
app[web.1]: spawn> child PID = 49
app[web.1]: ### ../controllers/messages_controller.rb:17:in `create_message': After spawn
app[web.1]: Task Load (1.2ms) SELECT "tasks".* FROM "tasks" WHERE "tasks"."id" = 80 LIMIT 1
app[web.1]: PGError: server closed the connection unexpectedly
app[web.1]: This probably means the server terminated abnormally
app[web.1]: before or while processing the request.
I have this option in my config/database.yml, following the recommendation of the spawn documentation:
reconnect: true
Is it connected to this do you think?
Bit at a loss with this... before i go investigating, does anyone know what's causing this?
cheers, max
I ended up using the girl_friday gem instead, which is a simple forked-queue system. It worked great for me.
for some reason whenever i try to spawn a server with rubber it gets stuck after compiling ruby-1.9.2.
If I SSH into the server, I see that before it finishes compiling, almost at the very end, the rubber script disconnects the connection.
** [out :: stageone.foo.com] ruby-1.9.2-p0 - #compiling
If I try to do cap rubber:bootstrap it fails at trying to install mongrel citing that my ruby installation might not be complete.
Fetching: mongrel-1.1.5.gem (100%)39%)
** Building native extensions. This could take a while...
** ERROR: Error installing mongrel:
** ERROR: Failed to build gem native extension.
**
** /usr/local/rvm/rubies/ruby-1.9.2-p0/bin/ruby extconf.rb
I'm trying to create a staging server using the "complete_mongrel_mysql" script.
any ideas?
Explanation is on the mailing list:
https://groups.google.com/d/msg/rubber-ec2/K-ahRFZpAAk/2fTJI5EeURwJ
Workaround checked into code for next release at:
https://github.com/wr0ngway/rubber/commit/64299e2005dcae9006273a6f915bf01dd8c87192