Vagrant not updating Files

July 25th, 2014 - Göttingen

This has been driving us nuts for almost a year. After switching from rsynced folders to NFS - which provides a more than noticeable speed boost -, we noticed that some files didn’t update on the VM, even after a sequence of carefully executed attempts to load the new version of the file (such as reloading the page like a mad man while crying…).

Some files appeared to be just cursed, and after using a fresh provisioned VM for some weeks things appeared to get worse. This is hard to verify since it could be a perception issue, and as a project grows with time the number of files naturally increases (which could be also playing a role). We now believe the origin of the problem to be an accumulation of corrupted cache files, which would be coherent with that observation.

In our Rails code, models and controllers usually got updated with issues, but the css and js files - which are compiled along with multiple related files - were just a nightmare. We started adding lines like console.log "random-number-123-please-work" and * {background: green !important} just to quickly assert that the files were being reloaded, and this was so discouraging that we considered giving up on vagrant altogether.

We have been looking for solutions without much success, I’ll list them beneath just in case they might also help.

For us this is the magic (and quite horrible) solution:

sudo su
sync; echo 3 > /proc/sys/vm/drop_caches

We run “sync” first in order to make sure all cached objects are freed, the next command makes the kernel drop clean caches, dentries and inodes from memory (see this link).

It is unclear for us what is going on with this cached files, but cleaning them up when we detect the error works like a charm. The hardcore version of this command would be:

watch -n1 "sync; echo 3 > /proc/sys/vm/drop_caches"

Which basically flushes the cache every second. Here there’s a solution to disabled page caching for a given application, but I haven’t tested it yet.

The other two possible culprits that we read about were the atomic saves in Sublime and the Sendfile option in nginx. We did as they suggested but it wasn’t enough in our case:


Sublime Text Atomic Save

This seems to be related to the NFS not picking up on changes in files whose size stays the same.

To disable it, go to > Preferences > Settings-User and add:

{
    "atomic_save": false
}



Nginx Sendfile

Nginx has a sendfile directive that allows to use the Linux kernel’s sendfile operation to read the requested file from disk. This is known to cause problems in VMs (is even listed in the nginx pitfalls section http://wiki.nginx.org/Pitfalls).

To disabled it just set this line in your nginx.conf:

sendfile off;



—–

After a long time searching I couldn’t come up with a better solution than dropping the caches, nor have we found a satisfactory explanation as to why this happen to us so often when updating js and css files (although we suspect that this is connected to the asset pipeline, and the multiple files concerned to update the application.js/css compiled file)

Here are all the relevant links that I could find on this subject: