Grails Watch Files doesn't work inside Docker container running inside VM on MAC


I am running grails application on:

  1. Docker Container which is running on…
  2. VirtualBox VM Boot2docker which is running on…
  3. MacOSX workstation.

The code directory is on MAC which is shared on VM and then from VM, it is mapped inside Docker container using -v option.

This way I can do development on my workstation and the Grails application at the bottom should (ideally) detect changes and recompile/reload on the fly. This is a feature that used to work when I was running the same application straight on the MacOSX, but now grails seems totally unaware of file changes. Of course, if I open the files with an editor (inside the Docker container) they are indeed changed and in fact if I stop/restart the grails app the new code is used.

I don’t know how grails implements the watch strategy, but if it depends on some operating system level feature I suspect that file change notifications get lost somewhere in the chain.

Anyone has an idea of what could be the cause and/or how I could go about debugging this?

In the latest release of docker (v1.10.1), docker seems to have addressed this issue and is working fine with nodejs as described in this video ( by Mano Marks, Docker Developer Relations Director). However this issue still exists when it comes to Grails.

Currently, we are relying on docker-osx-dev tool which keeps rsyncing the shared folders.



Are you using the Docker for Mac Beta to develop your Grails application?

The current public release of Docker Toolbox does not support file system event notifications. In the upcoming Docker for Mac application, which is still in private beta and is the product discussed in Mano’s video, we do support file system event notification.

Hi David,
Thanks for your response.
My bad! we are not using Docker for Mac Beta.

FWIW File system event notifications seem to be broken in beta8.

Attempting to watch certain file types (js) using a node fs watched (webpack) never picks up changes made on the host OS inside of the container.

Nevermind, I think I might have found a bug.

Hi Josh,

What are the circumstances of the bug? Do you have a reproducible test case?



Still trying to chase things down. I’m semi reliably (I think) getting the Docker daemon to crash, I just need to poke around in the logs more I think and come up with a simple way to reproduce.

I think this might be a Webpack bug as I am able to get file watching to work if use the “polling” method but that isn’t great because it is very CPU intensive.

I have tested the underlying library (chokidar) that Webpack uses and that seems to pick up file changes ok without using a polling method.

Should I pursue this with Webpack folks or could this still be a D4M issue?

It may be a D4M issue or a combination of D4M and the specific configuration of watched directories/symlinks/mounts. Do you have a simple way to replicate the issue?

The reproduction in Docker-compose volumes, gulp watch, 100% CPU usage is very similar to my own use case. I am going to keep an eye on that thread for the time being. I believe nodemon and webpack both use the same underlying mechanism (chokidar).

I will chime in if I uncover anything else. Thanks.