I am unable to run rake tasks with cron. The error it throws up is:-
/Library/Ruby/Gems/1.8/gems/bundler-1.2.0/lib/bundler/runtime.rb:199: warning: Insecure world writable dir /Library/Ruby/Gems/1.8 in PATH, mode 040777
/Library/Ruby/Gems/1.8/gems/bundler-1.2.0/lib/bundler/spec_set.rb:90:in `materialize': Could not find unf_ext-0.0.5 in any of the sources (Bundler::GemNotFound)
However, when I run the same rake task directly from the terminal, it works fine. In case of the cron job, as well as while running the rake task directly from the terminal, i cd into the (exact) same directory. Starting the rails server works as well.
What is the problem and how should I resolve this?
It could be an issue with your daemon user and your user when you're running it directly. Or it could be a problem with Ruby and/or your cron file commands.
Firstly, use this gem for making cron jobs with rake tasks:
https://github.com/javan/whenever
Then install RVM since you're using the standard ruby library provided by OSX and that can lead to some problems when you're developing various projects. This should fix the permissions error that you have displayed.
Related
I have deployed a rails application using capistrano on a linux server and it is running without any problems. When I connect to my remote server via ssh, the folder structure of my app is quite different from what I have on my local machine. I would like to go to project root and say rails console so that I can have access to the console of my application. Is there a way to achieve this?
When I go to ~MyApp/ folder and run rails console it says command rails not found. I think that is probably because the app is running in another folder.
bundle exec to the rescue inside of project folded:
$ RAILS_ENV=production bundle exec rails console
If you've installed with rbenv it could be that you are defaulting to the wrong Ruby version. So you can run rbenv exec to get it to run on the right version, along with bundle exec to run the right version of Rails
So try running this:
rbenv exec bundle exec rails console
To sum up for anyone having the same problem in the future,
I went to MyApp/releases/2020331231231231 which is the latest release of my app and there I used this command RAILS_ENV=production bundle exec rails console and I was able to do whatever I wanted to do in the console.
First you need to move inside the folder where the code is.
Check Capistrano config if deploy_to is defined. (If it's not it should be set to /var/www/#{application}/ by default read here)
Since Capistrano keep older versions of your app go to the current folder which is a symlink of the latest deployed version.
And run ENVIRONMENT=production bundle exec rails c or ENVIRONMENT=production bin/rails c. If doesn't work try with rbenv ENVIRONMENT=production rbenv exec bundle exec rails c
What does bundle exec rake db:migrate really means? or bundle exec rails s
I understand that bundle handle all the gems we specify in our Gemfile,and rake handle all the things which you can do through scripts but these commands don't get executed without prefixing bundle exec and I couldn't find any documentation about this on internet !!
Bundler - The best way to manage your application's dependencies
Run the command in context of the bundle
$ bundle exec
Exec runs a command, providing it access to the gems in the bundle. While using bundle exec you can require and call the bundled gems as if they were installed into the systemwide RubyGems repository
With:
bundle exec rake db:migrate
In an informal way, it means that your rails environment will
-Install dependencies with bundler
then
-Run your database migrations in your rails app (/yourapp/db/migrate)
Instead of a database operation, you could do any other command line stuff that can be controlled by rake (like building your app, extensions, cleaning some files, etc.)
This can be useful if you want to avoid confusing scenarios where maybe some gems in your setup are outdated, or missing from your environment. It's a good practice because calling rake by itself will not guarantee that you got all your dependencies in check.
Bundler acts to create a somewhat isolated Ruby language programming environment separate from the underlying host system. There are limits to what it can do. For example, you need something like RVM to manage different versions of the Ruby language virtual machine. And of course both Ruby and Bundler itself have to be available outside your project in order to run.
However, within a single project bundle exec will restrict access to gems installed by Bundler into that project. This means that the Rake utility when invoked via bundle exec will be the version of rake installed in your project and not the system-wide version. It also means that `bundle rake db:migrate' will use the correct version of rails installed for your project. This isolates your project from updates done to the Ruby environment on the host and thereby prevents compatibility issues from arising.
You can get around the verbosity by creating aliases in your .bash_profile (assuming you are using OSX or Linux/unix) for bundle exec, bundle exec rake and bundle exec rails. I use bexec, brake and brails.
I'm moving a Rails app (written by somebody else) from running on an OSX server to a CentOS server and during my setup process I am trying to create the database using the command...
/usr/bin/bundle exec /usr/bin/rake db:create RAILS_ENV=production POSTGRES_DIR=/usr
This call fails with the error:
libc.dylib: cannot open shared object file: No such file or directory
Which makes no sense to me at all, dylib files are an OSX thing and so I don't know why the Rails db:create operation would be looking for libc.dylib? Shouldn't it just load up the standard Linux libc.so?
What is db:create actually executing that has this dependency?
My repository had a cache of .gem files generated by the bundler when running on OSX and submitted to source control. One of those gems was an OSX binary, the db:create call runs through the all the initializer code to execute the calls to the ORM and so even though those modules were not being used during the db:create functions they were attempting to load.
I have installed sphinx and have done all necessary changes followed this steps
wget http://www.sphinxsearch.com/downloads/sphinx-0.9.9.tar.gz
tar -xzf sphinx-0.9.9.tar.gz
After that, we should compile Sphinx from the source:
cd sphinx-0.9.9-rc2/
./configure
sudo make
sudo make install
In Rails 3, open Gemfile in the root directory and add the line below:
gem 'thinking-sphinx', :git => 'http://github.com/freelancing-god/thinking-sph
And run the following command:
bundle install
Thinking Sphinx gem adds a few rake tasks to your application. The most important ones:
rake thinking_sphinx:index – Create the index
rake thinking_sphinx:reindex – Reindex Sphinx without regenerating the configuration file
rake thinking_sphinx:start – Start up Sphinx's daemon
rake thinking_sphinx:stop – Shut down the daemon
but getting error FATAL: no indexes found in config file '/home/gvo/dcms/config/development.sphinx.conf'
but when i run same with RAILS_ENV= production it works fine. Any suggestion or help would be really great.
Yeah, those names are confusing. You need to make sure the ThinkingSphinx configuration in app/config/sphinx.yml (paths, what to index) is available to the TS gem for your environment. TS uses this config to generate the configuration used by the underlying Sphinx server. You may have to create needed directories for the indexer to be able to write index files, logs, and a few other things. It's likely that the config for development is different than production.
In Rails 2 you're able to run
script/console --sandbox
so you can play with production data and not accidentally break anything.
I can't seem to find the equivalent command for Rails 3. Does anyone know what it is?
Easy, type in:
bundle exec rails c -s
and that is it.
$ bundle exec rails c --help
Usage: console [environment] [options]
-s, --sandbox Rollback database modifications on exit.
--debugger Enable ruby-debugging for the console.
--irb DEPRECATED: Invoke `/your/choice/of/ruby script/rails console` instead
It is simple, but, sometimes, if you are not running rails executable using bundle exec, it may, or may not, result in an error. In order to avoid this, ALWAYS use bundle exec.
To quote bundler page (if not documentation):
In some cases, running executables without bundle exec may work, if
the executable happens to be installed in your system and does not
pull in any gems that conflict with your bundle.
However, this is unreliable and is the source of considerable pain.
Even if it looks like it works, it may not work in the future or on
another machine.