Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Guard not running after a file change #357

Closed
dfischer opened this Issue Nov 2, 2012 · 57 comments

Comments

Projects
None yet

dfischer commented Nov 2, 2012

I installed rb-fsevent and after I change a spec the suite isn't running.

The only way to trigger it is to hit enter.

My prompt looks like this:

[2] guard(main)> 

Which is unique for this project. I haven't noticed this before. Any tips to investigate issue?

Owner

rymai commented Nov 2, 2012

Hi, please respect the guidelines for contributing so we're able to understand your issue and help you.

Thank you in advance.

dfischer commented Nov 2, 2012

Sorry, thank you. Attaching missing files.

guard 'rspec', :version => 2 do
  watch(%r{^spec/.+_spec\.rb$})
  watch(%r{^lib/(.+)\.rb$})     { |m| "spec/lib/#{m[1]}_spec.rb" }
  watch('spec/spec_helper.rb')  { "spec" }

  # Rails example
  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/#{m[1]}_spec.rb" }
  watch(%r{^app/(.*)(\.erb|\.haml)$})                 { |m| "spec/#{m[1]}#{m[2]}_spec.rb" }
  watch(%r{^app/controllers/(.+)_(controller)\.rb$})  { |m| ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb", "spec/acceptance/#{m[1]}_spec.rb"] }
  watch(%r{^spec/support/(.+)\.rb$})                  { "spec" }
  watch('config/routes.rb')                           { "spec/routing" }
  watch('app/controllers/application_controller.rb')  { "spec/controllers" }

  # Capybara request specs
  watch(%r{^app/views/(.+)/.*\.(erb|haml)$})          { |m| "spec/requests/#{m[1]}_spec.rb" }

  # Turnip features and steps
  watch(%r{^spec/acceptance/(.+)\.feature$})
  watch(%r{^spec/acceptance/steps/(.+)_steps\.rb$})   { |m| Dir[File.join("**/#{m[1]}.feature")][0] || 'spec/acceptance' }
end

Guardfile

gem 'rails', '3.0.9'
gem 'rake', '0.9.2'

group :test, :development do
  gem "rspec-rails", "~> 2.4"
  gem "ruby-prof"
  gem "test-unit"
  gem 'rb-inotify', :require => false
  gem 'rb-fsevent', :require => false
  gem 'rb-fchange', :require => false
  gem 'terminal-notifier-guard'
  gem 'database_cleaner'
  gem 'factory_girl_rails'
  gem 'guard'
  gem 'guard-rspec'
end

Gemfile

Owner

rymai commented Nov 2, 2012

Ok, thanks. Are you sure the file you save is catch by a watch definition, and if yes, is there a spec file that correspond to it?

dfischer commented Nov 3, 2012

Yes, I'm changing a file in

spec/controllers.

If I try something in spec/models I don't get anything triggered either. I'm using the same Guardfile on another project that does catch it.

Also I don't know why Guard is returning with a prompt like this [35] guard(main)> Killed:

Owner

rymai commented Nov 3, 2012

Does the issue still occur if you use polling instead of rb-fsevent?

Since version 1.5.0, Guard is using Pry as its interactor, that's why you see this prompt: [2] guard(main)>.

dfischer commented Nov 3, 2012

How long does it take to poll? I commented out the rb-fsevent gem and it doesn't seem like anything updated after 1 minute waiting.

Owner

rymai commented Nov 3, 2012

Default latency for polling is 1 second.

A few more hints to find the issue:

  • run Guard in debug mode;
  • ensure again that the issue is not related to your watch definitions. For instance, create a watch('a/specific/path/that/exists.rb') { 'a/specific/spec/file/that/exist_spec.rb' }, save 'a/specific/path/that/exists.rb' and see if the associated spec is run.

If you still don't find the issue, please also share your Gemfile.lock.

dfischer commented Nov 3, 2012

Still doesn't seem to detect a write to that file.

I used

  watch('spec/controllers/hello_controller_spec.rb')  { 'spec/controllers/hello_controller_spec.rb' }

And nada on change.

GEM
  remote: http://rubygems.org/
  specs:
    aaronh-chronic (0.3.9)
    abstract (1.0.0)
    actionmailer (3.0.9)
      actionpack (= 3.0.9)
      mail (~> 2.2.19)
    actionpack (3.0.9)
      activemodel (= 3.0.9)
      activesupport (= 3.0.9)
      builder (~> 2.1.2)
      erubis (~> 2.6.6)
      i18n (~> 0.5.0)
      rack (~> 1.2.1)
      rack-mount (~> 0.6.14)
      rack-test (~> 0.5.7)
      tzinfo (~> 0.3.23)
    active_shipping (0.9.13)
      activesupport (>= 2.3.5)
    activemerchant (1.17.0)
      activesupport (>= 2.3.11)
      braintree (>= 2.0.0)
      builder (>= 2.0.0)
      json (>= 1.5.1)
    activemodel (3.0.9)
      activesupport (= 3.0.9)
      builder (~> 2.1.2)
      i18n (~> 0.5.0)
    activerecord (3.0.9)
      activemodel (= 3.0.9)
      activesupport (= 3.0.9)
      arel (~> 2.0.10)
      tzinfo (~> 0.3.23)
    activeresource (3.0.9)
      activemodel (= 3.0.9)
      activesupport (= 3.0.9)
    activesupport (3.0.9)
    addressable (2.2.7)
    arel (2.0.10)
    bcrypt-ruby (3.0.1)
    braintree (2.11.0)
      builder (>= 2.0.0)
    builder (2.1.2)
    cancan (1.6.5)
    capistrano (2.13.4)
      highline
      net-scp (>= 1.0.0)
      net-sftp (>= 2.0.0)
      net-ssh (>= 2.0.14)
      net-ssh-gateway (>= 1.1.0)
    carrierwave (0.5.6)
      activesupport (~> 3.0)
    ckeditor (3.6.0)
      mime-types (~> 1.16)
      orm_adapter (~> 0.0.5)
    client_side_validations (3.1.0)
    cocaine (0.1.0)
    coderay (1.0.8)
    database_cleaner (0.9.1)
    devise (1.5.3)
      bcrypt-ruby (~> 3.0)
      orm_adapter (~> 0.0.3)
      warden (~> 1.1)
    diff-lcs (1.1.3)
    erubis (2.6.6)
      abstract (>= 1.0.0)
    exception_notification_rails3 (1.2.0)
    factory_girl (4.1.0)
      activesupport (>= 3.0.0)
    factory_girl_rails (4.1.0)
      factory_girl (~> 4.1.0)
      railties (>= 3.0.0)
    faraday (0.7.6)
      addressable (~> 2.2)
      multipart-post (~> 1.1)
      rack (~> 1.1)
    fastercsv (1.5.4)
    gdata_19 (1.1.5)
    guard (1.5.3)
      listen (>= 0.4.2)
      lumberjack (>= 1.0.2)
      pry (>= 0.9.10)
      thor (>= 0.14.6)
    guard-rspec (1.2.1)
      guard (>= 1.1)
    hashie (1.2.0)
    highline (1.6.15)
    i18n (0.5.0)
    json (1.7.5)
    listen (0.5.3)
    lumberjack (1.0.2)
    mail (2.2.19)
      activesupport (>= 2.3.6)
      i18n (>= 0.4.0)
      mime-types (~> 1.16)
      treetop (~> 1.4.8)
    meta_where (1.0.4)
      activerecord (~> 3.0.0)
      activesupport (~> 3.0.0)
      arel (~> 2.0.7)
    method_source (0.8.1)
    mime-types (1.16)
    multi_json (1.1.0)
    multipart-post (1.1.5)
    mysql (2.8.1)
    mysql2 (0.2.7)
    net-scp (1.0.4)
      net-ssh (>= 1.99.1)
    net-sftp (2.0.5)
      net-ssh (>= 2.0.9)
    net-ssh (2.6.1)
    net-ssh-gateway (1.1.0)
      net-ssh (>= 1.99.1)
    nokogiri (1.5.5)
    oauth2 (0.5.2)
      faraday (~> 0.7)
      multi_json (~> 1.0)
    omniauth (1.0.3)
      hashie (~> 1.2)
      rack
    omniauth-facebook (1.2.0)
      omniauth-oauth2 (~> 1.0.0)
    omniauth-oauth2 (1.0.0)
      oauth2 (~> 0.5.0)
      omniauth (~> 1.0)
    orm_adapter (0.0.6)
    paperclip (2.3.16)
      activerecord (>= 2.3.0)
      activesupport (>= 2.3.2)
      cocaine (>= 0.0.2)
      mime-types
    polyglot (0.3.2)
    pry (0.9.10)
      coderay (~> 1.0.5)
      method_source (~> 0.8)
      slop (~> 3.3.1)
    rack (1.2.5)
    rack-mount (0.6.14)
      rack (>= 1.0.0)
    rack-test (0.5.7)
      rack (>= 1.0)
    rails (3.0.9)
      actionmailer (= 3.0.9)
      actionpack (= 3.0.9)
      activerecord (= 3.0.9)
      activeresource (= 3.0.9)
      activesupport (= 3.0.9)
      bundler (~> 1.0)
      railties (= 3.0.9)
    railties (3.0.9)
      actionpack (= 3.0.9)
      activesupport (= 3.0.9)
      rake (>= 0.8.7)
      rdoc (~> 3.4)
      thor (~> 0.14.4)
    rake (0.9.2)
    rdoc (3.9.1)
    rmagick (2.13.1)
    rspec (2.11.0)
      rspec-core (~> 2.11.0)
      rspec-expectations (~> 2.11.0)
      rspec-mocks (~> 2.11.0)
    rspec-core (2.11.1)
    rspec-expectations (2.11.3)
      diff-lcs (~> 1.1.3)
    rspec-mocks (2.11.3)
    rspec-rails (2.11.4)
      actionpack (>= 3.0)
      activesupport (>= 3.0)
      railties (>= 3.0)
      rspec (~> 2.11.0)
    ruby-prof (0.10.8)
    rvm-capistrano (1.2.7)
      capistrano (>= 2.0.0)
    slop (3.3.3)
    smurf (1.0.6)
    sqlite3 (1.3.4)
    sqlite3-ruby (1.3.3)
      sqlite3 (>= 1.3.3)
    terminal-notifier-guard (1.5.3)
    test-unit (2.4.0)
    thor (0.14.6)
    treetop (1.4.10)
      polyglot
      polyglot (>= 0.3.1)
    tzinfo (0.3.29)
    warden (1.1.1)
      rack (>= 1.0)
    whenever (0.6.8)
      aaronh-chronic (>= 0.3.9)
      activesupport (>= 2.3.4)

PLATFORMS
  ruby

DEPENDENCIES
  active_shipping
  activemerchant
  awesome_nested_set!
  bcrypt-ruby
  cancan
  capistrano (~> 2.13.4)
  carrierwave
  ckeditor (~> 3.6.0)
  client_side_validations
  database_cleaner
  devise
  exception_notification_rails3
  factory_girl_rails
  fastercsv
  gdata_19
  guard
  guard-rspec
  json (~> 1.7.3)
  meta_where
  mysql (= 2.8.1)
  mysql2
  nokogiri
  omniauth-facebook
  paperclip
  rails (= 3.0.9)
  rake (= 0.9.2)
  rmagick
  rspec-rails (~> 2.11.4)
  ruby-prof
  rvm-capistrano
  smurf
  sqlite3-ruby
  terminal-notifier-guard
  test-unit
  whenever

dfischer commented Nov 3, 2012

What's odd is that polling doesn't seem to work either.

Contributor

netzpirat commented Nov 3, 2012

Are you running Guard with Bundler?

bunde exec guard

Can you provide the debug output of Guard?

bunde exec guard -d

Can you test if the watch expression is working properly by output a log statement like:

watch(%r{^app/controllers/(.+)_(controller)\.rb$})  do  |m| 
  run = ["spec/routing/#{m[1]}_routing_spec.rb", "spec/#{m[2]}s/#{m[1]}_#{m[2]}_spec.rb", "spec/acceptance/#{m[1]}_spec.rb"]
  puts "Should run now: #{ run.inspect }"
  run
end

Since 1.5.x I've had similar issues where a file is run once and thereafter no further changes are detected, or they are only detected after a 30-60 second delay. This is with rb-fsevent.

With polling the behavior is the same, the delay is just longer. (3-5 minutes)

In my case I'm absolutely 100% certain the correct files are being watched, (a) because they do run, just after a crazy delay, and (b) because this same guardfile has been working on this app for a long time.

I'm looking into this further and will post more information if I can figure anything else out.

Contributor

netzpirat commented Nov 3, 2012

Can you please test the cleanup branch? This branch has removed some threading code, which may solve the problem:

gem 'guard', :github => 'guard/guard', :branch => 'interactor/cleanup'

Thanks...

On cleanup branch the performance seems marginally better, but I'm still having a large delay with files. Let me try and describe the behavior I'm observing:

It seems like Guard will only run a test every 30-45 seconds. If nothing has changed in that long, then it will run a test almost immediately after a file change.

However, if a test has been run within the last 30-45 seconds, then any subsequent file change will not trigger a test run until a delay of 30-45 seconds.

This is on the cleanup branch with both fsevent and polling.

Owner

thibaudgg commented Nov 3, 2012

@burlesona have you a lot of files in the watched directory?

@thibaudgg I have about 20-30 files total in there.

Owner

thibaudgg commented Nov 3, 2012

Really weird, can you try to move them in another folder (maybe out of Dropbox) and try it again. Thanks!

I am having the same problem as @dfischer. I have tried using the polling, debug doesnt seem to show any errors. I have also verified that rb-fsevent is working by running their same script https://github.com/thibaudgg/rb-fsevent#singular-path in the same directory.

Owner

rymai commented Nov 3, 2012

Could you all try to downgrade to 1.4.0 and let us know if the issue is still here or not?

Hi @rymai I downgraded to 1.4.0 and that resolved my issue.

@rymai Downgrading to 1.4.0 improved my issue. There is still a noticeable lag between saving a file and a test being triggered if the file that is saved just passed all tests.

ie: save - red(no lag) - save - green(no lag) - save - (lag)

However it is much less than on the later version.

For reference, here is my guardfile:

guard 'pow' do
  watch('.powrc')
  watch('.powenv')
  watch('Gemfile')
  watch('Gemfile.lock')
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.*\.rb$})
  watch(%r{^config/initializers/.*\.rb$})
end

guard 'spork', :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.+\.rb$})
  watch(%r{^config/initializers/.+\.rb$})
  watch('Gemfile')
  watch('Gemfile.lock')
  watch('spec/spec_helper.rb')
end

guard 'rspec', :all_on_start => false, :all_after_pass => false do
  watch(%r{^spec/.+_spec\.rb$})
  watch(%r{^app/(.+)\.rb$})                           { |m| "spec/#{m[1]}_spec.rb" }
  watch(%r{^lib/(.+)\.rb$})                           { |m| "spec/lib/#{m[1]}_spec.rb" }
  watch(%r{^spec/support/(.+)\.rb$})                  { "spec" }
  watch('spec/spec_helper.rb')                        { "spec" }
  # watch('config/routes.rb')                           { "spec/routing" }
  watch('app/controllers/application_controller.rb')  { "spec/controllers" }
  watch(%r{^app/views/(.+)/.*\.(erb|haml)$})          { |m| "spec/requests/#{m[1]}_spec.rb" } # Capybara request specs
end

and Gemfile

group :development, :test do
    gem 'sqlite3'
    gem 'debugger'
    gem 'rspec-rails'
    gem 'capybara'
    gem 'spork'
    gem 'rb-fsevent'
    gem 'guard', '1.4.0'
    gem 'guard-spork'
    gem 'guard-rspec'
    gem 'guard-pow'
    gem 'growl'
end

Note: After originally posting I noticed there were a few duplicated lines in my guardfile twice. I revised my guardfile to take those out (edited revisions in above), and re-ran all the test cases discussed in this thread so far, and that did not affect my results.

The best I can tell, something that happens after a test passes all green consumes a lot of computer horsepower. I notice that when a test run is all green the computer cranks away for a while, in Activity Monitor CPU useage jumps to 30-50% and stays there for a while, then when it cools down it runs the next test.

There is no output in the terminal though, so I don't know what it's doing behind the scenes.

dfischer commented Nov 3, 2012

Downgrading to 1.4 solved my issue.

Contributor

netzpirat commented Nov 4, 2012

I still have the problem that I'm unable to reproduce the issue. Can you guys please share some info about your environment (OS X and Ruby version, project folder shared with Dropbox or NFS)? Perhaps you have something in common that could give us a hint.

It would be interesting to see if using Pry from master would have an influence on the problem (the latest stable release is 4 months old), by adding this to your Gemfile

gem 'pry', :github => 'pry/pry', :branch => 'master'

@netzpirat Adding that like to my Gemfile produces the following error

You passed :github as an option for gem 'pry', but it is invalid.

I am using
Bundler 1.0.21
OS X 10.7.5
Ruby 1.9.2
Local disk drive, no Dropbox/NFS
Rails 3.1.3

Ruby 1.9.3-p194
Bundler 1.1.5
OS X 10.8.2
Rails 3.2.8

Local disk drive, no cloud stuff. Not sure pry would affect, because my issue is roughly the same in 1.4x as it is in 1.5x.

At least on my end I feel like I'm getting a memory leak or something. It's really weird.

dfischer commented Nov 4, 2012

Same as Andrew.

On Sun, Nov 4, 2012 at 11:05 AM, Andrew Burleson
notifications@github.comwrote:

Ruby 1.9.3-p194
Bundler 1.1.5
OS X 10.8.2
Rails 3.2.8

Local disk drive, no cloud stuff.


Reply to this email directly or view it on GitHubhttps://github.com/guard/guard/issues/357#issuecomment-10053965.

Owner

thibaudgg commented Nov 5, 2012

@kfalconer You need to upgrade Bundler (>= 1.2)

Contributor

netzpirat commented Nov 5, 2012

If you've tested the latest Pry without success, let us start with an empty project, just to see if it's a Guard issue or a combination of plugins that leads to the problem. Please create an empty directory an add the following Gemfile:

source :rubygems
gem 'guard'
gem 'rb-fsevent'

Next create a Guardfile without ant plugin dependency:

require 'guard/guard'

module ::Guard
  class InlineGuard < ::Guard::Guard
    def run_on_changes(paths)
      puts "Got change for: #{ paths.inspect }"
    end
  end
end

guard :inline_guard do
  watch(%r{.*})
end

Now install the gems and run Guard:

$ bundle
$ bundle exec guard
13:17:08 - INFO - Guard uses TerminalTitle to send notifications.
13:17:08 - INFO - Guard is now watching at '/Users/michi/Desktop/test'
[1] guard(main)> 

Now try to trigger an event directly from within Guard like:

[1] guard(main)> .touch hello
[2] guard(main)> Got change for: ["hello"]

If this doesn't work, disable the notifications in the Guardfile by adding:

notification :off

and run again:

$ bundle exec guard
13:19:53 - INFO - Guard is now watching at '/Users/michi/Desktop/test'
[1] guard(main)> .touch hi
[2] guard(main)> Got change for: ["hi"]

If that doesn't work, disable the interactor in the Guardfile by adding:

interactor :off

and run Guard in the background and test it with:

$ bundle exec guard &
[1] 45087
13:21:47 - INFO - Guard is now watching at '/Users/michi/Desktop/test' 

$ touch hihi
Got change for: ["hihi"]

$ kill 45087

@netzpirat Unfortunately, none of these things worked. Here are the results:

Initial Guard File Result

08:41:04 - INFO - Guard uses TerminalTitle to send notifications.
08:41:04 - INFO - Guard is now watching at '/Users/kfalconer/workspace/guard_test'
[1] guard(main)> .touch hello
[2] guard(main)> exit
[2] guard(main)> exit
/Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/listen-0.5.3/lib/listen/listener.rb:55:in `stop': undefined method `stop' for nil:NilClass (NoMethodError)
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/guard-1.5.3/lib/guard.rb:173:in `stop'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/guard-1.5.3/lib/guard/cli.rb:106:in `rescue in start'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/guard-1.5.3/lib/guard/cli.rb:103:in `start'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/gems/guard-1.5.3/bin/guard:6:in `<top (required)>'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/bin/guard:19:in `load'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/bin/guard:19:in `<main>'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/bin/ruby_noexec_wrapper:14:in `eval'
    from /Users/kfalconer/.rvm/gems/ruby-1.9.2-p290@guard_test/bin/ruby_noexec_wrapper:14:in `<main>'

With notifications off I also had no result, and when typing exit the app hung.

Guard Background Test - Looks like Guard crashed

Cardadmins-MacBook-Pro-2:guard_test kfalconer$ bundle exec guard &
[2] 18442
Cardadmins-MacBook-Pro-2:guard_test kfalconer$ touch hihi

[2]+  Stopped                 bundle exec guard
Cardadmins-MacBook-Pro-2:guard_test kfalconer$
Contributor

netzpirat commented Nov 5, 2012

@kfalconer Ok, thanks. I see two interesting things. First, you're using rubygems-bundler, so you should not prefix Guard with bundle exec. Second, Guard fails to properly exit, since the Listen gem has no adapter found (listener.rb:55:instop': undefined method stop' for nil:NilClass). Can you go to your normal project, start Guard and enter the following into the Guard console:

[1] guard(main)> Guard.listener.adapter.class
=> Listen::Adapters::Darwin

@dfischer, @burlesona Do you guys use rubygems-bundler?

@netzpirat I don't use rubygems-bundler. I'll run the tests you spelled out as soon as I get a chance. Thanks!

bricker commented Nov 6, 2012

Same issue here. Everything worked with guard 1.4.0, but after upgrading to 1.5.3, guard doesn't run on file change. Guardfile, gems, bundle version, etc. are untouched. Even saving Guardfile itself doesn't do anything.

  • Guard 1.5.3
  • Pry 0.9.10
  • Mac OS X 10.7.4
  • RVM, Ruby 1.9.3-p0
  • Bundler 1.2.1

Some extra information:

  • I am not using rubygems-bundler.
  • I am running guard via bundle exec guard.
  • When I type exit, the app hangs. The return key works as expected.

borgand commented Nov 6, 2012

I have the same issue - guard <= 1.4.0 works fine, but >= 1.5.0 does not detect file changes. I have also verified in IRB that rb-fsevents itself does see the changes.

I followed @netzpirat testcase and got Guard to respond with the last test interactor :off. I also verified that when removing notification :off still works. So the problem seems somewhere in the interactor thing.

require 'guard/guard'

module ::Guard
  class InlineGuard < ::Guard::Guard
    def run_on_changes(paths)
      puts "Got change for: #{ paths.inspect }"
    end
  end
end

guard :inline_guard do
  watch(%r{.*})
end

interactor :off    # <--- adding this gets things working

My versions:

$ ruby -v                                                                                                                           [10:16:57]
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-darwin10.4.0]

$ gem list                                                                                                                          [10:19:53]

*** LOCAL GEMS ***

bundler (1.2.1, 1.0.0)
coderay (1.0.8)
guard (1.5.3)
listen (0.5.3)
lumberjack (1.0.2)
method_source (0.8.1)
pry (0.9.10)
rake (0.8.7)
rb-fsevent (0.9.2)
slop (3.3.3)
thor (0.16.0)

$ system_profiler SPSoftwareDataType                                                                                                [10:21:41]
Software:

    System Software Overview:

      System Version: OS X 10.8.2 (12C60)
      Kernel Version: Darwin 12.2.0

My files are all local and nothing is shared nor clouded.

For the time being, I'm downgrading to 1.4.0

Contributor

netzpirat commented Nov 6, 2012

I still have no clue what causes the issue, because I can't reproduce it. I guess the interactor thread swallows an exception, hiding the cause from us. So I changed the threading code a bit and Guard will now also set Thread.abort_on_exception to true when in debug mode.

Can you guys please make sure that you're using the latest rubygems and Bundler versions:

$ cd ~
$ gem update --system
$ gem update

And use Guard from the master branch, by adding

gem 'guard', :github => 'guard/guard', :branch => 'master'

to your Gemfile and run bundle update. Now start Guard in debug mode and we should see now any exception that occurs in the Listen and the Interactor thread.

$ bundle exec guard -d

Also updating to the latest Pry version is interesting, since a lot has happend on Pry master in the last 4 months:

gem 'pry', :github => 'pry/pry', :branch => 'master'

Thanks a lot.

borgand commented Nov 6, 2012

Still nothing.

My versions

$ gem update --system
Latest version currently installed. Aborting.

$ gem --version
1.8.24

$ gem update
Updating installed gems
Nothing to update

$ bundle show
Gems included by the bundle:
  * bundler (1.2.1)
  * coderay (1.0.8)
  * guard (1.5.3 251c74a)
  * listen (0.5.3)
  * lumberjack (1.0.2)
  * method_source (0.8.1)
  * pry (0.9.10 322313e)
  * rb-fsevent (0.9.2)
  * slop (3.3.3)
  * thor (0.16.0)

I run guard:

$ bundle exec guard -d
13:41:53 - DEBUG - Command execution: emacsclient --eval '1' 2> /dev/null || echo 'N/A'
13:41:53 - INFO - Guard uses TerminalTitle to send notifications.
13:41:53 - INFO - Guard is now watching at '/Users/laas/proged/guardtest'
13:41:53 - DEBUG - Hook :start_begin executed for Guard::InlineGuard
13:41:53 - DEBUG - Command execution: hash stty
13:41:53 - DEBUG - Command execution: stty -g 2>/dev/null
13:41:53 - DEBUG - Start interactor
[1] guard(main)> 

When I touch a file in another terminal window, nothing happens.

The same thing with interactor :off in Guardfile:

$ bundle exec guard -d
13:57:03 - DEBUG - Command execution: emacsclient --eval '1' 2> /dev/null || echo 'N/A'
13:57:03 - INFO - Guard uses TerminalTitle to send notifications.
13:57:03 - INFO - Guard is now watching at '/Users/laas/proged/guardtest'
13:57:03 - DEBUG - Hook :start_begin executed for Guard::InlineGuard

But when I touch a file, it outputs:

13:57:05 - DEBUG - Trying to run Guard::InlineGuard#run_on_modifications with ["hello"]
13:57:05 - DEBUG - Hook :run_on_changes_begin executed for Guard::InlineGuard
Got change for: ["hello"]
13:57:05 - DEBUG - Hook :run_on_changes_end executed for Guard::InlineGuard

Just to make sure, I run this in bundle exec irb:

require 'listen'

Listen.to(Dir.pwd) do |*args|
  puts "Got change: #{args.inspect}"
end

And when I touched a file, it outputs:

Got change: [["/Users/laas/proged/guardtest/hello"], [], []]

So, Listen gem itself detects changes.

Contributor

netzpirat commented Nov 6, 2012

Can you check if Listen has an active adapter?

[1] guard(main)> ::Guard.listener.adapter
Contributor

netzpirat commented Nov 6, 2012

Ok, I can now reproduce it in Ruby 1.9.2-p320. Looks like the interactor thread blocks the listener thread. I'll keep you updated...

Contributor

netzpirat commented Nov 6, 2012

Can you please add

gem 'rb-readline'

to your Gemfile and see if that resolves the issue for you?

borgand commented Nov 6, 2012

Yay! Adding rb-readline did the job!

Meanwhile I wrote myself a small threaded guard clone to test the issue.
If I use the MyInteractor thread, everything works, but if I switch to MyPry thread, it blocks just as in Guard.

Confirmed, that adding rb-readline to that testcase also fixes issue there.

Also, if its of any help still, I found that I could start listener from Pry console and then it blocks until first fsevent is received:

[1] guard(main)> ::Guard.listener.start
14:21:33 - DEBUG - Stop interactor
14:21:33 - DEBUG - Command execution: stty gfmt1:cflag=4b00:iflag=6b02:lflag=200005cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=ff:erase=7f:intr=3:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400 2>/dev/null 
14:21:33 - DEBUG - Trying to run Guard::InlineGuard#run_on_modifications with ["hello"]
14:21:33 - DEBUG - Hook :run_on_changes_begin executed for Guard::InlineGuard
Got change for: ["hello"]
14:21:33 - DEBUG - Hook :run_on_changes_end executed for Guard::InlineGuard
14:21:33 - DEBUG - Command execution: stty -g 2>/dev/null
14:21:33 - DEBUG - Start interactor
[1] guard(main)>

@netzpirat netzpirat closed this in 56fd807 Nov 6, 2012

Contributor

netzpirat commented Nov 6, 2012

Please visit https://github.com/guard/guard/wiki/Add-proper-Readline-support-to-Ruby-on-Mac-OS-X to add proper readline support to Ruby on OS X.

Owner

thibaudgg commented Nov 6, 2012

Really nice catch! Well done!

bricker commented Nov 6, 2012

+1, rb-readline seems to have fixed it for me.

@netzpirat When I tried the test you prescribed (creating an empty project), guard worked fine.

Then I tried adding rb-readline, and it made no difference in my app. Side note: can you add to your rb-readline page, is there any way to check and see which ruby build you have, ie. see if this is likely the issue?

So, I must have a different problem. To recap, here's what is happening:

When running guard in my app, the first spec run will go fine, but any subsequent spec runs take anywhere from 1-5 minutes to be picked up. Interestingly, if I save a file after the first spec run, while it is waiting and waiting to be picked up, I can hit enter and guard will immediately start running all specs. Eventually, sometime after all specs have run, the file I saved before I ran all specs will run.

Now, I tried guard 1.4x and 1.5x, no difference. I tried with and without rb-readline, no difference.

I was thinking that maybe it is a problem with guard-spork, since the specs run fine manually, so I removed guard-spork and tried that. No difference, same exact behavior.

Just to double check, I ran spork outside of guard, and with spork running I can manually run many specs in a row, back to back, no perceptible delay between one spec finishing and the next one firing. So, that doesn't seem to be it.

I tried with and without guard-pow, no difference there either.

I tried removing growl. No difference.

I did all of the above test with rb-readline gem, and it had no effect.

So, at this point, my issue is something different. Guard runs fine in an empty project. Rspec and Spork run fine on their own. But somehow the combination of the above is causing guard to become unresponsive to file system events (the pry console is still responsive) after the first event.

*After doing all the above, I found a lead: *

[1] guard(main)> ::Guard.listener.adapter

This responds if I run it immediately after running guard (before any file system events).

This responds if I run it after manually trigger all specs run (hit enter) but no file system events.

This does not respond if I run it after a file system event, it just hangs forever.

So, that's the first thing from this thread I've found that doesn't do what it is 'supposed to' (besides taking forever to pick up file system changes).

Any suggestions for what to try next?

@netzpirat @thibaudgg : Should I open a new issue for the problem I'm still having, since it seems different from what worked for everyone else on this thread?

Owner

thibaudgg commented Nov 7, 2012

@burlesona yes please.

Contributor

netzpirat commented Nov 7, 2012

@burlesona looks like your issue is different, since this one is about the listener being completely blocked, whereas your issue is about a lag, but it doesn't happen without other Guard plugins. It would be great to start over with a new issue.

You can use the test case from @borgand to see if you have the readline issue: https://gist.github.com/4024548

In your case, I would upgrade to the latest Ruby (ruby-1.9.3-p286 instead of ruby-1.9.3-p194) and add proper readline support to it, see https://github.com/guard/guard/wiki/Add-proper-Readline-support-to-Ruby-on-Mac-OS-X

Also upgrade to Bundle 1.2.1 and run Guard from the master branch.

borgand commented Nov 7, 2012

I seem to have a little glitch still, which might be related to the readline:

When I start guard, pry prompt works as expected, I can hit Enter to run all tests etc.

But when Guard detects a file change and runs specific task for it, then from that moment on, the pry prompt stops working - instead of submitting the command, it inserts ^M characters.

Listen still keeps detecting file changes and running tasks, but I can't run all tasks anymore, until I stop Guard with ^C or ^D.

I can debug this a bit later, but maybe you can already guide me in some direction.

@ghost

ghost commented Nov 11, 2012

Installing rb-readline resolved this issue for me.

I'm running ruby 1.8.7 with rails 3.2.5, and guard 1.5.4

Adding the rb-readline gem also fixed this same issue for me

guard 1.5.3
ruby 1.9.2p290
rails 3.2.8

borgand commented Nov 21, 2012

It turned out that rb-readline caused the ^M characters and even in Rails Console when I started typing before console was finished loading.

Only difference was that Rails Console submitted the lines when it finished and afterwards all was OK. Guard only submitted the line when I followed it up with ^D, which then run the command (e.g. run all tests) and then exited the Guard session.

I was able to fix this when I installed latest Ruby 1.9.3 with native readline from Homebrew as suggested in the wiki page.

Now I'm able to run commands from Pry console and also detect file changes.

Contributor

netzpirat commented Nov 21, 2012

Thanks for the info. I'll update the wiki page...

fgarcia commented Sep 3, 2014

After reading this thread, none of the previous solutions did work for me. Neither rb-readline and/or rb-fsevent did solve the problem.

Also I tried recompiling with my own readline but it did not work either (with or without the mentioned ruby gems). My build was something like this:

RUBY_CONFIGURE_OPTS=--with-readline-dir=`brew --prefix readline` ruby-build 2.1.1 /opt/rubies/2.1.1

Now, the only thing that is different from most people who had this problem is that I am using chruby.

I tried versions 2.1.1 and 2.1.2 of Ruby on Mavericks.

My Guardile and Gemfile at:

https://gist.github.com/fgarcia/5caf58e5835a077d4158

Contributor

e2 commented Sep 14, 2014

@fgarcia - check the guard/listen readme (https://github.com/guard/listen) for possible causes, especially the LISTEN_GEM_DEBUGGING=2 environment variable and the '-d' option in guard.

(The output with those set will help find out what's wrong).

Same thing here..

Using guard 2.14.0
Using guard-rspec 4.7.1

It works on first attempt and then nothing happens when the file is modified again.

Contributor

e2 commented Jun 2, 2016

@giedriusr - open an new issue, because too much has changed since. Especially on the debugging side.

Check out the Troubleshooting section here to help pinpoint the problem: https://github.com/guard/guard/wiki/Understanding-Guard#debugging

If nothing else, the MINIMUM I need to help you is output from this: https://github.com/guard/guard/wiki/Understanding-Guard#nope-watched-dirs-are-fine-and-i-still-dont-see-any-changes

Contributor

e2 commented Jun 2, 2016 edited

NOTE: IF YOU STILL HAVE ISSUES:

Open a NEW issue here: https://github.com/guard/guard/issues/new and provide as MUCH debugging output as you can. See:

https://github.com/guard/guard/wiki/Understanding-Guard

While you're waiting, go through the above troubleshooting page on the wiki. If the wiki is unclear somewhere (or it plain sucks), just open a new issue for that and let me know I've screwed up or obfuscated something.

The first thing I WOULD try is: upgrade all related gem to their latest versions, e.g.:

$ gem update listen guard rb-inotify rb-fsevent

And make sure those versions are used in your project. You can even make sure by running gem cleanup.

I'm locking this thread simply to encourage opening new issues, since they're guaranteed to be unrelated. Every latest version of Guard is expected to either work flawlessly or show a useful error/warning message.

If you're having an issue, I want to know. And I want to know the details too, so if it's a bug, I can fix-and-release quickly.

@e2 e2 locked and limited conversation to collaborators Jun 2, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.