Listen falls back to polling intermittently on script execution

[meeech]

Sometimes when I run this code from CLI: https://gist.github.com/3628881,
Listen falls back to polling. No idea why.
When Listen works as expected, I can see in activity monitor 'fsevent_watch' process
When Listen falls back to polling, I can see 'fsevent_watch' process did not launch.
Not getting any error messages (beyond default 'Listen will be polling changes...')

Can you offer any advice on what I can do to gather more information to track down why this is happening?

Don't know if this is related to #60. I tried explicitly require'ing rb-fsevent in the script but that doesn't seem to make a difference.

OSX: 10.6.8
Ruby: 1.8.7
rb-fsevent: 0.9.1
Listen: 0.5.0

[thibaudgg]

Have you tried to increase latency (0.5) ?

[meeech]

yes. tried 1.0 as well. same result
m

Sent from my iPhone

On 2012-09-05, at 2:08 AM, Thibaud Guillaume-Gentil notifications@github.com wrote:

Have you tried to increase latency (0.5) ?

�
Reply to this email directly or view it on GitHub.

[thibaudgg]

Same on ruby 1.9.3?

[thibaudgg]

Oh and have you tried everything in the list? https://github.com/guard/listen#polling-fallback

[meeech]

Yes, tried everything on the list.

re: ruby 1.9.3 - the script needs to work with default osx ruby. So thats what I have setup on my system.

[thibaudgg]

Ok weird, can you try to launch the Listen spec suite on your system please.

[mattgreen]

I'm seeing similar behavior:

OSX: 10.8
Ruby: 1.9.3
rb-fsevent: 0.9.1
Listen: 0.5.0

There were two failures in the spec suite:

  1) Listen::Adapters::Darwin it should behave like an adapter that call properly listener#on_change when multiple directories are listened to when a file is moved between the multiple watched directories detects the movements of the file
     Failure/Error: array.should include("#{path1}/from_directory", path2, "#{path3}/to_directory")
       expected ["/Users/matt/Projects/listen/spec/.fixtures/1346883696658592382", "/Users/matt/Projects/listen/spec/.fixtures/1346883696658592382/from_directory", "/Users/matt/Projects/listen/spec/.fixtures/13468836966586978446"] to include "/Users/matt/Projects/listen/spec/.fixtures/1346883696658592382/from_directory", "/Users/matt/Projects/listen/spec/.fixtures/134688369665866025240", and "/Users/matt/Projects/listen/spec/.fixtures/13468836966586978446/to_directory"
     Shared Example Group: "an adapter that call properly listener#on_change" called from ./spec/listen/adapters/darwin_spec.rb:11
     # ./spec/support/adapter_helper.rb:596:in `block (6 levels) in <top (required)>'
     # ./spec/support/adapter_helper.rb:7:in `block in watch'
     # ./lib/listen/adapter.rb:196:in `call'
     # ./lib/listen/adapter.rb:196:in `report_changes'
     # ./spec/support/adapter_helper.rb:22:in `watch'
     # ./spec/support/adapter_helper.rb:603:in `block (5 levels) in <top (required)>'
     # ./spec/support/fixtures_helper.rb:24:in `fixtures'
     # ./spec/support/adapter_helper.rb:594:in `block (4 levels) in <top (required)>'

  2) Listen::Adapter.works? does work
     Failure/Error: adapter_class.works?(path).should be_true
       expected: true value
            got: false
     # ./spec/listen/adapter_spec.rb:157:in `block (5 levels) in <top (required)>'
     # ./spec/support/fixtures_helper.rb:24:in `fixtures'
     # ./spec/listen/adapter_spec.rb:156:in `block (4 levels) in <top (required)>'

[thibaudgg]

Ok I got the same issue sometimes, I'll try to have a look this week. We'll maybe need to increase latency.

Failures:

  1) Listen::Adapter.works? does work
     Failure/Error: adapter_class.works?(path).should be_true
       expected: true value
            got: false
     # ./spec/listen/adapter_spec.rb:157:in `block (5 levels) in <top (required)>'
     # ./spec/support/fixtures_helper.rb:24:in `fixtures'
     # ./spec/listen/adapter_spec.rb:156:in `block (4 levels) in <top (required)>'

Finished in 32.47 seconds
248 examples, 1 failure

[thibaudgg]

I have create a new branch (adatper_work_test) to test specifically this issue, and it seems that adapter.wait_for_callback method do not wait enough. @Maher4Ever have you an idea about how to fix that? @turnstile.wait isn't working properly?

@mattgreen @meeech can you try to run bundle exec rspec spec in that branch to see if you got the same result:

Running: spec/listen/adapter_spec.rb
Run options:
  include {:focus=>true}
  exclude {:broken=>true}

Listen::Adapter
  .works?
"before wait_for_callback: work == false"
"after wait_for_callback: work == false"
"work = true"
"after sleep: work == true"
    does work

Finished in 0.97743 seconds
1 example, 0 failures

Thanks!

[meeech]

@thibaudgg I tried running bundle exec rspec spec on that branch, i get the following error:

/Users/mitch/src/listen/spec/spec_helper.rb:8: undefined method `order=' for #           <RSpec::Core::Configuration:0x1017e3568> (NoMethodError)
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core.rb:71:in `configure'
from /Users/mitch/src/listen/spec/spec_helper.rb:6
from /Users/mitch/src/listen/spec/listen/adapter_spec.rb:1:in `require'
from /Users/mitch/src/listen/spec/listen/adapter_spec.rb:1
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/configuration.rb:459:in `load'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/configuration.rb:459:in `load_spec_files'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/configuration.rb:459:in `map'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/configuration.rb:459:in `load_spec_files'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/command_line.rb:18:in `run'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/runner.rb:80:in `run_in_process'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/runner.rb:69:in `run'
from /Users/mitch/.gem/ruby/1.8/gems/rspec-core-2.7.1/lib/rspec/core/runner.rb:10:in `autorun'
from /Users/mitch/.gem/ruby/1.8/bin/rspec:19

@thibaudgg ps: i'm in the guard IRC room if you want to do this realtime.

[thibaudgg]

@meeech I think you don't have the last rspec version, try to run bundle update before.
@meeech Github issue is fine, so everybody have the backlog, thanks!

[meeech]

@thibaudgg thanks. works now.

Run options:
  include {:focus=>true}
  exclude {:broken=>true}

Listen::Adapter
  .works?
"before wait_for_callback: work == false"
"work = true"
"after wait_for_callback: work == true"
"after sleep: work == true"
    does work

Finished in 1.12 seconds
1 example, 0 failures

Randomized with seed 45972

Ran it 5 times, each time no failure.

[thibaudgg]

@meeech with the sleep 0.5 it seems to always works, but the "after wait_for_callback: work == false" should never happens. Do you also got it sometimes?

[meeech]

@thibaudgg the 5 times i ran before, each time "after wait_for_callback: work == true"

I just ran the test again, this time i got a failure:

Run options:
  include {:focus=>true}
  exclude {:broken=>true}

Listen::Adapter
  .works?
"before wait_for_callback: work == false"
"after wait_for_callback: work == false"
"after sleep: work == false"
    does work (FAILED - 1)

Failures:

  1) Listen::Adapter.works? does work
     Failure/Error: adapter_class.works?(path).should be_true
       expected: true value
            got: false
     # ./spec/listen/adapter_spec.rb:157
     # ./spec/support/fixtures_helper.rb:24:in `fixtures'
     # ./spec/listen/adapter_spec.rb:156

Finished in 1.12 seconds
1 example, 1 failure

Failed examples:

rspec ./spec/listen/adapter_spec.rb:155 # Listen::Adapter.works? does work

Randomized with seed 56942

Ran again a few time after this one failure, and no more failures.

[thibaudgg]

Ok so even with sleep 0.5 it isn't rock solid

[mattgreen]

Tried the branch, can't get it to fail.

[Maher4Ever]

@thibaudgg This issue seems to be Mac specific (which isn't at my disposal at the moment). I can't reproduce it on neither Windows nor Linux. I'll try to take a look at the problem this weekend on a Mac.

[thibaudgg]

@Maher4Ever awesome thanks!

[Maher4Ever]

This issue was a tricky one, but I think a fixed the cause of the bug. Could you try the master branch and tell me if the fix works for you?

[meeech]

@Maher4Ever working for me. Fired off the test script a number of times, never once fell back to polling. thanks!

[zakdances]

This issue is not resolved, please re-open. I'm still experiencing this with Listen 0.5.0 (Mac OSX 10.7.4). The error does not occur with Listen 0.4.7

[meeech]

@zakdances i closed it because the fix was on master, and its working. They haven't pushed out an update yet to rubygems.
@thibaudgg @Maher4Ever whats your pref - would you rather this stay open till you push out 0.5.1?

[zakdances]

Is there an ETA for the rubygems push?

[nilbus]

master fixes this bug for me too.

It doesn't really matter when it gets released on Rubygems. Point your Gemfile to the git repository in the mean time:

  gem 'listen', :git => 'git://github.com/guard/listen.git'

[thibaudgg]

@Maher4Ever I'm ok for 0.5.1 if it's ok for you too :)

gem 'listen', github: 'guard/listen'

Is even better :) (Ruby 1.9 & Bundler 1.2)

[Maher4Ever]

Thanks to everyone who helped track this bug down and test the fix. I just released 0.5.1 to rubygems.