Vagrant: rsync auto broken on mac os X

[fearlsgroove]

Using Vagrant > 1.8.1 on mac os x (10.11.5 for me), rsync-auto is forced into polling. I think this is due to this issue in the bundled listen. Reverting to 1.8.1 resolves the issue for me.

Edit: here's the mess I see warning me about using polling for rsync auto:

D, [2016-06-13T20:11:16.207144 #2313] DEBUG -- : Adapter: considering polling ...
D, [2016-06-13T20:11:16.207208 #2313] DEBUG -- : Adapter: considering optimized backend...
rb-fsevent > 0.9.4 no longer supports OS X 10.6 through 10.8.

Please add the following to your Gemfile to avoid polling for changes:
  require 'rbconfig'
  if RbConfig::CONFIG['target_os'] =~ /darwin(1[0-3])/i
    gem 'rb-fsevent', '<= 0.9.4'
  end
D, [2016-06-13T20:11:16.209327 #2313] DEBUG -- : Adapter: falling back to polling...
[Listen warning]:
  Listen will be polling for changes.Learn more at https://github.com/guard/listen#listen-adapters.

What's most odd is it seems to be complaining about using an old version of OSX (< 10.9), but I'm using 10.11 ... Maybe it's a bug in the upstream gem? I can't reproduce with a simple Listen example though using locally installed gems:

$ gem list

*** LOCAL GEMS ***

bigdecimal (1.2.8)
did_you_mean (1.0.0)
ffi (1.9.10)
io-console (0.4.5)
json (1.8.3)
listen (3.1.5)
minitest (5.8.3)
net-telnet (0.1.1)
power_assert (0.2.6)
psych (2.0.17)
rake (10.4.2)
rb-fsevent (0.9.7)
rb-inotify (0.9.7)
rdoc (4.2.1)
ruby_dep (1.3.1)
test-unit (3.1.5)

[sethvargo]

Hi @fearlsgroove

We just released 1.8.4 - can you give that a try please? If it's not working, please include the full debug output as a gist.

[bjorxi]

Just upgraded to vagrant 1.8.4 but rsync-auto still doesn't work
https://gist.github.com/leemalmac/32b1cee936bc7d80d83eb37af8cded25

It is my first experience with rsync-auto, so I can't tell anything about previous versions

[bjorxi]

Seems that vagrant already use rb-fsevent 0.9.7, and I use OS X 10.11

[fearlsgroove]

FWIW I had also already tried 1.8.4 (saw it in previous versions even though the download link was still 1.8.3), but like @leemalmac I still had the same issue.

[fearlsgroove]

Sorry didn't see that you'd asked for a debug gist. Hera ya go!
https://gist.github.com/fearlsgroove/47cccc14751b961c3c89cf4ea63bd744

[bjorxi]

@sethvargo Awesome, thanks.
How can I get this fix? Vagrant version on vagrantup.com is 1.8.4

[sethvargo]

You can build from source (instructions in wiki) or wait until the next release.

[danez]

I haven't tried to build from source, but I'm not sure if it will solve the problem. After investigating I found that the check in the listen gem is not working as expected and detecting macOS 10.11 as 10.8. Maybe this is solved with the ruby update, but then it might be always reporting a newer macOS version and not work for older macOs versions.

https://github.com/guard/listen/issues/404

[fearlsgroove]

I'm running from source and this change fixes the issue for me -- I see it's using listen 3.1.5 and I'm no longer polling when running rsync-auto on OS X 10.11

[danez]

ok good to know, thanks.

[danez]

With 1.8.5 still not working, I still get the warning.

So it might be what I wrote here: guard/listen#404

[pansen]

a hacky solution for Vagrant 1.8.5 is:

sudo vim /opt/vagrant/embedded/gems/gems/listen-3.1.5/lib/listen/adapter/darwin.rb +31

and change that line to contain:

return true if fsevent_version >= Gem::Version.new('0.9.4')

the comparision in that gem is wrong imo.

(sorry, no ruby coder here, i'm happy if it works like this. )

[adejongh]

This is still broken with vagrant 1.8.5 - can this issue be reopened?

[benprew]

See my notes on https://github.com/guard/listen/issues/404 . Vagrant is reporting the wrong version of darwin, or at least a different version than the system ruby reports. This causes fsevent to think the darwin adapter is unusable.

I'm not sure how RbConfig::CONFIG['target_os'] is set, but it doesn't appear to be correct in the vagrant embedded ruby.

[benprew]

Looks like it's part of the vagrant embedded ruby lib:

embedded/lib/ruby/2.2.0/universal-darwin12.0/rbconfig.rb
187:  CONFIG["target_os"] = "darwin12.0"

[adejongh]

Yes, I agree it is an issue with something in vagrant - I have run the polling test code from the listen project (for 3.1.5) and that works fine. However, in vagrant it does not. The hacky fix in https://github.com/mitchellh/vagrant/issues/7441#issuecomment-233655940 works for now if you know your version of darwin is ok.

[jswierad]

Confirmed - vagrant 1.8.5 this is broken.

➤ vagrant --version
Vagrant 1.8.5
➤ ruby --version
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin15]

rb-fsevent > 0.9.4 no longer supports OS X 10.6 through 10.8.

Please add the following to your Gemfile to avoid polling for changes:
  require 'rbconfig'


  if RbConfig::CONFIG['target_os'] =~ /darwin(1[0-3])/i
    gem 'rb-fsevent', '<= 0.9.4'
  end
[Listen warning]:
  Listen will be polling for changes.Learn more at https://github.com/guard/listen#listen-adapters.
rb-fsevent > 0.9.4 no longer supports OS X 10.6 through 10.8.

Please add the following to your Gemfile to avoid polling for changes:
  require 'rbconfig'
  if RbConfig::CONFIG['target_os'] =~ /darwin(1[0-3])/i
    gem 'rb-fsevent', '<= 0.9.4'
  end

Somebody needs to rewrite vagrant in Golang one day... ;)

[agilgur5]

@sethvargo can you re-open this as it's still broken? @benprew has done some great digging to find the root of the problem.

This also doesn't just affect rsync, but anything that uses listen (and based on the information here, likely _any_ gem that checks OS versions), such as vagrant-fsnotify, which also polls as a result of this and devours CPU

[danimbrogno]

@pansen's suggestion worked for me, is this a safe change to make? Once this issue is resolved and I update vagrant will this workaround be overwritten?

[hoshy]

It still doesn't for for me with Vagrant 1.9.1 on macOS Sierra. Please re-open!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.