Having a weird issue and need help.
I am trying to start a rails console on a production server and it is acting like the rails c command does not exist.
FWIW, I have been a rails developer for 4 years and do this all the time on a plethora of other servers without issue. On this server, I can drop, create, migrate, seed the database with no problems (using RAILS_ENV=production), and the app works fine live without any issues.
Setup:
Ubuntu 14.04 (racksapce 2nd gen performance 1 server)
Nginx with Passenger (I typically use Unicorn, but have never had a problem on any of the apps I have deployed with Passenger)
Ruby 2.1.5 (using rvm)
Rails 4.1.7
Postgres
Capistrano 3 (using the rvm, migrations, asset-precompilation, etc. extensions)
What I've tried:
cd into app directory:
cd /home/deployer/app_name/current
Which loads .rvmrc and shows that I am in the correct gemset, ran bundle just for kicks.
rails c production # (which usually works no problem)
bundle exec rails c production # (sometimes have to do this on older apps that do not have the newer capistrano 3 and rvm setup)
rails c production RAILS_ENV=production # (getting desperate here)
RAILS_ENV=production rails c production # (haha, surely this won't work, but out of options)
RAILS_ENV=production bundle exec rails console
Every time, I get a notice that implies 'rails c' is not a valid command:
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
..... yada yada, shows the rest of the rails options (oddly enough does not show 'c' or 'console' as options?)
Again, I have logged into hundreds of production consoles on both nginx/apache deployed with old and new versions of both Unicorn and mostly older versions of Passenger.
This is the first time I have ever gotten this message, and the console is the ONLY thing that seems to be broken - everything else works fine! the app is live and works great.
I know that the first thing to be suggested is that I am not running rails c production from the app directory - I have cd'd into the correct directory at least 10 times and manually loaded the correct gemset, this is not the issue.
Can't figure out why it works fine in development, but not in production. I know there used to be a scripts directory a while back (maybe rails 2?)- Is there still a directory that contains the script commands for rails that may have been corrupted?
Has anyone ever experienced this before or have any suggestions?
I feel like I am missing something.
Ok, found the issue... #stoodfarback was pretty close, but I thought the cause of the issue needed to be mentioned for others who might encounter the same thing.
Basically I am using a newer version of Capistrano (3.3.5) than I have used in the past and it (by default) adds 'bin' to the list of shared directories that it symlinks on each deploy.
set :linked_dirs, fetch(:linked_dirs, []).push('bin', 'log', 'tmp', 'public/system', "public/downloads", "public/assets")
So the deploy script created a new directory in shared called bin (which was empty) and the files used to launch rails server and console were missing. They were obviously still there in development, so it only affected production.
Removed 'bin' from the linked_dirs list and everything now works as expected.
now looks like:
set :linked_dirs, fetch(:linked_dirs, []).push('log', 'tmp', 'public/system', "public/downloads","publ ic/assets")
I have noticed on the last few versions of Capistrano that I have used, the format and defaults for linked_dirs keeps changing quite a bit, but I had never seen bin in that list. Not really sure why bin would need to be symlinked... it only has the default rails files and I can't think of why they would need to be removed from source control, but maybe the Capistrano team has a reason.
Hope this helps someone.
Check if you have any of these files and try deleting them:
script/rails
bin/rails
Related
I amm using Rails 5, and I have half way deployed my app through Capistrano on server. due to specific need to loadschema, i ssh in and cd into the release/### directory and tried to run
rails --version # came out 5.0.3beta
bundle # works, everything installed
rails c # but this fail
running rails db:migrate also failed.
it seems to return rails generic help as like my directory isn't a rails directory.
i tried deleting bin folder, but still the same.
anyone know what could be wrong?
thank you
It seems you're using capistrano to deploy your application. Have a look at this issue: https://github.com/capistrano/bundler/issues/45
The solution would be:
remove bin from the linked_dirs
add set :bundle_binstubs, nil to your config/deploy.rb to generate the binstubs
To run the console try rails console. To run a migration try rake db:migrate
I'm working against a variety of constraints that are troubling an EC2 Rails deployment. I'm not allowed to use Capistrano because I cannot save this application to any public git repository (like GitHub) and I also need to retain complete control over which instance on EC2 the Rails application is installed to and be able to modify this easily (adding load balancers, auto-scalers, etc.) on the fly from the AWS Console, so I also cannot use Rubber.
I finally resorted to simply ssh'ing my Rails application directory over to the EC2 instance, but am running into a 'no such file to load' error when running bundle install, specifically the Time gem. Because this is an 'integrated' gem, I think I might just be overlooking something simple. Here are the things that I've tried:
I've used RVM to manage my versions of ruby, rails, rubygems, etc.
Deleting my Gemfile.lock file and re-running bundle-install
Including 'Time' in my GemFile and re-running bundle-install
This application runs without issue on my local development environment, so what am I overlooking?
Note: I am REQUIRED to host on a single EC2 instance. Otherwise, I'd simply deploy to EBS, Heroku, etc.
This was a stupid mistake, also detailed in this question: heroku - cant run rake db:migrate - no such file --Time
I incorrectly had a require statement in a controller for 'Time', instead of 'time'. This was allowed locally, but my ubuntu server ruby environment was not as forgiving. Changing the 'T' to a 't' in my controller and running 'bundle install' resolved this issue completely.
After updating to Rails 4, I'm trying to start the server, but it won't start. Simply put, the application doesn't seem to get "detected", like there is no application in there.
~ $ bundle exec rails server
Usage:
rails new APP_PATH [options]
Options:
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /app/vendor/ruby-2.0.0/bin/ruby
-b, [--builder=BUILDER] # Path to some application builder (...
-m, [--template=TEMPLATE] # Path to some application template (...
[--skip-gemfile] # Don't create a Gemfile
-B, [--skip-bundle] # Don't run bundle install
What is weird is that the (older) system gem will make it start just fine, but not with Bundler.
Why won't Rails start?
I tried navigating the CLI source code, but I can't grip what's going on.
(Using Edge Rails 4.0.0.beta and Ruby 2.0.0.rc)
In case you're wondering, here's the directory listing:
~ $ ls
app config db Gemfile lib mock Rakefile script tmp
bin config.ru features Gemfile.lock log public README.md spec vendor
Rails 4 did change the way it boots up.
Fortunately, you don't have to run rails-new, since there is a handy task for that.
Rails 4 Release Notes:
6.1 Notable changes
Your app's executables now live in the bin/ dir. Run rake rails:update:bin to get bin/bundle, bin/rails, and bin/rake.
Mostly, I've been had by my own laziness. (Even though laziness is the mother of efficiency ;o) ) I've made a point of not using Bundle when running Rails server.
Rails 4.0.0.beta changes the way it boots up. But, since I was using my "old" version of Rails, an older 4.0.0-beta I had lying around in my local gems, which didn't have the change, I didn't notice when the change was made to my bundle.
Now, when came the time to deploy, the obligatory bundle-exec couldn't boot because my code was used to boot the old way.
The solution
Do like the message says to: bundle exec rails new .. And use Bundle this time! At that point, Rails will generate the boilerplate stuff, namely the missing boot files like ./bin/rails.
It will also update some config files, and try to overwrite some stuff. In my case, everything is checked into source control, so there's a bit of diff'ing and choosing whether to overwrite or not and reverting after.
An maybe better idea (I haven't bothered to) would be to branch out in Git, run the "upgrade" rails-new, overwrite everything, commit that, and then three-way merge back with the main branch.
If your bin folder is already in place, you may just need to run bundle install first. This solved the problem for me after cloning a repo that was working perfectly on another machine.
I noticed that when I set my Rails app to production it created a folder in my application called RAILS_ENV=production I've kinda rolled back now and not pushing to production. Am I free to delete this folder?
The "rails" command in Rails 2 creates a new app, while the same in Rails 3 runs script/... so it looks like you've installed an old version of Rails on your production server.
If it's your development machine, this can happen when you have rvm installed with different versions of rails.
I have now fixed this issue, there was a 'PATH' setting in my bundler config file that kept re-creating the folder when I updated my bundle. I removed the path declaration and now it uses the default path.
I've inherited a rails site that I need to deploy (quickly!) to our webhost, which is a standard *nix shared server that uses FastCGI for rails apps. I've worked with rails sites on multiple occasions in the past but wouldn't consider myself an expert by any stretch.
This particular app was developed using capistrano, with which I've got no experience, and everything I've read leads me to believe that to deploy the app "properly" would require my setting up an external svn account, among other things, which aren't feasible given our time frame and hosting situation.
My question is: what is the best way to quickly get this application up and running without using capistrano? I received, along with the site files, a .sql dump that I've already imported, and I've configured config/database.yml to reflect the correct production db settings. Right now, running ruby script/console production yields the following error message:
/home/user1/ruby/gems/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:443:in `load_missing_constant':NameError: uninitialized constant ApplicationController
Thanks for your consideration!
As the others already stated, you are probably using the incorrect version.
Rails switched from app_controller to application_controller (or something like that) in version 2.1 or 2.2.
There is a rake task that you should be able to run in that case:
rake rails:update:application_controller
It might help you.
As for the capistrano. In your deploy.rb you can add the parameter :deploy_via :
set :deploy_via, :copy
set :scm, :none
And it should use the copy you are having in your working directory to deploy with (no need for subversion or any other version control)
Copy usually fetches the code from a repository locally and then uploads it to the server, but also setting the :scm to none it should ignore that and just (hopefully) use your working copy instead.
All capistrano requires is a deploy.rb and a Capfile, this is not what is causing your error. From the looks of it it seems that the problem is that you're using a gem rails version which is incompatible with your app, do you know which version it was developed with? If so you should try vendoring your rails directory to the right version.
For deployment, if you're using FastCGI you can just upload the files to the host and set the appropriate permissions and you should be good to go. Going forward you might want to look at upgrading to a newer version of rails, using capistrano and changing your environment to use apache passenger.
I hope this helps.
The problem you're running into appears to be a mismatch of your installed version and the version that the app is expecting. Look in config/environment.rb, Toward the top you'll see something that looks like:
RAILS_GEM_VERSION = '2.3.4'
You need to make sure that the version of rails installed on your machine matches whatever version is declared in that file. You can do that by running:
sudo gem install -v=X.X.X rails
where X.X.X matches what was in your environment.rb.
Jonnii is suggesting you "freeze" your rails by including all the rails code into your project directly, (which can be done by running rake rails:freeze:gems AFTER you have followed the above steps and gotten the correct gems installed in the first place.) Once you've frozen rails, then you no longer need to have the rails gems installed on your webserver machine.
Good luck!