Vagrant Does not Start RSync-Auto on Up or Reload

[joebobmiles]

Vagrant version

Version 2.0.2 (latest version available via Fedora's repositories)

Host operating system

Fedora 28

Guest operating system

CentOS 7

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "centos/7"

  config.vm.synced_folder ".", "/vagrant", type: "rsync",
        rsync__auto: true

  config.vm.network "forwarded_port", guest: 80, host: 8080

  config.vm.provision "shell", inline: <<-SHELL
    yum -y update
    yum -y install httpd mariadb mariadb-server
  SHELL
end

Debug output

https://gist.github.com/JoeBobMiles/e7063ac42066302fcdfbed3c42a5a9e1

This gist has two log files, one for when rsync__auto is set to false and the other when rsync__auto is set to true. Both show that rsync__auto was parsed correctly. However, there was no indication of rsync-auto being started when rsync__auto was set to true.

Expected behavior

When rsync__auto is enabled (set to true), Vagrant starts rsync-auto in the background when the VM is started. The Vagrant documentation for RSync synced folders says that this should be what happens.

Actual behavior

rsync__auto was set to true, but Vagrant did not start rsync-auto when VM started.

Steps to reproduce

1. Add the line config.vm.synced_folder ".", "/vagrant", type: "rsync", rsync__auto: true to Vagrantfile.
2. Run vagrant up (or vagrant reload) to start (or restart) VM.
3. Create a new file called test.txt in host folder.
4. vagrant ssh into guest.
5. ls contents of /vagrant, test.txt will not be there.

References

There is a related issue (https://github.com/hashicorp/vagrant/issues/9604?_pjax=%23js-repo-pjax-container) regarding the vagrant-digitalocean plugin.

[joebobmiles]

After running across some similar issues where the problem had been attributed to the centos/7 box, I checked to see if it this issue was replicable in other boxes. After testing debian/jessie64 and generic/ubuntu1710, I found that the issue was replicable across multiple boxes.

If it is of any interest, I'm using the libvirt provider.

[ghost]

Is there, in the meantime, a solution for this?

[joebobmiles]

The only way I've come across to work around this is to run vagrant rsync-auto & in the shell to manually run rsync-auto in the background. I've also done some poking around in the source for the rsync plugin and I can't find any place where the configuration parameters were being passed to the plugin. I could be completely mistaken, seeing as I have limited knowledge of Ruby and the Vagrant code base, but it seems like the rsync plugin ignores the user specified configurations given in the Vagrantfile.

[briancain]

Hi there @JoeBobMiles @joernbrenner - from the docs, this is working as intended. See issue #3350 and the docs:

rsync__auto (boolean) - If false, then rsync-auto will not watch and automatically sync this folder. By default, this is true.

I will open a pull request to document this option not actually invoking the command rsync-auto, since there seems to be confusion about it. But this option is not about automatically invoking the rsync-auto command if the option is present in your Vagrantfile. If you want something automatic, you could use a trigger to invoke rsync-auto for a guest:

config.vm.define "bork" do |b|
    b.vm.box = "base"

    b.trigger.after :up do |t|
      t.info = "rsync auto"
      t.run = {inline: "vagrant rsync-auto bork"}
      # If you want it running in the background switch these
      #t.run = {inline: "bash -c 'vagrant rsync-auto bork &'"}
    end

    b.vm.synced_folder ".", "/vagrant", type: "rsync"
end

Edit: The guest name to rsync-auto is only required if you are trying this in a multi-vm environment, otherwise you can remove it from the rsync-auto arguments.

[joebobmiles]

Thank you @briancain for the clarification and the phrasing is indeed very misleading.

[briancain]

I've updated the docs with a note now about this. It should go live the next time we do a release. Thanks!

[ghost]

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.