How to bypass the warning when running 'rake sunspot:solr:reindex'?

223 views
Skip to first unread message

Drew Sheneman

unread,
Apr 24, 2013, 12:21:06 PM4/24/13
to capis...@googlegroups.com
I am trying to deploy Sunspot Solr to a server using a Capistrano in my RoR application. I have a task to reindex:

  desc "reindex the whole database"
  task :reindex, :roles => :app do
    stop
    run "rm -rf #{shared_path}/solr/data"
    start
    run "cd #{current_path} && RAILS_ENV=#{rails_env} bundle exec rake sunspot:solr:reindex"
  end


When Capistrano tries to execute this task I get the warning:

  * executing "cd /home/username/apps/appname/current && RAILS_ENV=production bundle exec rake sunspot:solr:reindex"
    servers: ["0.0.0.0"]
    [10.0.63.19] executing command
 ** [out :: 0.0.0.0] *Note: the reindex task will remove your current indexes and start from scratch.
 ** [out :: 0.0.0.0]
 ** [out :: 0.0.0.0] If you have a large dataset, reindexing can take a very long time, possibly weeks.
 ** [out :: 0.0.0.0]
 ** [out :: 0.0.0.0] This is not encouraged if you have anywhere near or over 1 million rows.
 ** [out :: 0.0.0.0]
 ** [out :: 0.0.0.0] Are you sure you want to drop your indexes and completely reindex? (y/n)
 ** [out :: 0.0.0.0]

The task just hangs at this point and cannot complete. I have been searching for ways to bypass this warning, however haven't found any surprisingly. Any help is appreciated.

Lee Hambley

unread,
Apr 24, 2013, 12:25:00 PM4/24/13
to capistrano
First things first, report this to the solr developers, they shouldn't be prompting for input unless stdin is a tty.

And then change your task to be:

  desc "reindex the whole database"
  task :reindex, :roles => :app do
    stop
    run "rm -rf #{shared_path}/solr/data"
    start
    run "cd #{current_path} && yes | RAILS_ENV=#{rails_env} bundle exec rake sunspot:solr:reindex"
  end


Note the addition of `yes |` this should echo "y" onto std in forever (thus it'll say yes to any program that asks for input) - if that doesn't work, you can also do `echo myanswer | RAILS_ENV.............` (echo something specific) - if neither of those things work solr is too badly behaved and you'll have to resort to `gnu expect` but that's almost certainly going to make you very, very unhappy.

--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
---
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Drew Sheneman

unread,
Apr 24, 2013, 12:50:44 PM4/24/13
to capis...@googlegroups.com
Your first suggestion worked like a charm. Saved me lots of frustration. Thanks!

On Wednesday, April 24, 2013 12:25:00 PM UTC-4, Lee Hambley wrote:First things first, report this to the solr developers, they shouldn't be prompting for input unless stdin is a tty.

And then change your task to be:

  desc "reindex the whole database"
  task :reindex, :roles => :app do
    stop
    run "rm -rf #{shared_path}/solr/data"
    start
    run "cd #{current_path} && yes | RAILS_ENV=#{rails_env} bundle exec rake sunspot:solr:reindex"
  end


Note the addition of `yes |` this should echo "y" onto std in forever (thus it'll say yes to any program that asks for input) - if that doesn't work, you can also do `echo myanswer | RAILS_ENV.............` (echo something specific) - if neither of those things work solr is too badly behaved and you'll have to resort to `gnu expect` but that's almost certainly going to make you very, very unhappy.



On 24 April 2013 18:21, Drew Sheneman <drewsh...@gmail.com> wrote:
The task just hangs at this point and cannot complete. I have been searching for ways to bypass this warning, however haven't found any surprisingly. Any help is appreciated. --
Reply all
Reply to author
Forward
0 new messages