Inotify events not triggering for deper nested files in React.js app

Expected behavior

File change anywhere in my file tree should trigger inotify event and trigger watchers in Container

Actual behavior

Some files, when saved, do not produce any notification to watcher


OS X: version 10.10.5 (build: 14F27) version v1.11.0-beta6
Running diagnostic tests:
[OK] docker-cli
[OK] Moby booted
[OK] driver.amd64-linux
[OK] vmnetd
[OK] osxfs
[OK] db
[OK] slirp
[OK] menubar
[OK] environment
[OK] Docker
[OK] VT-x
Docker logs are being collected into /tmp/20160406-155846.tar.gz.
Your unique id in bugsnag is: C3840C49-C706-42EA-9F2B-C10CEF7CD3D8
Please quote this in all correspondence.

Steps to reproduce the behavior

I have been developing this app heavily using Docker for some months. I use a dev setup that involves an rsync based syncer to push changes from OS X into a docker-machine. With no changes, using Docker for Mac, I can get my app to boot (albeit much slower), but only the top level component of my React.js based application triggers the Webpack watcher. Deeper components when modified or saved do not.

If I switch back to my rsync + docker-machine based implementation, the watcher is triggered just fine.

If you have any suggestions on how I might be able to provide better debug info, let me know.

Hi Adam,

Does the directory hierarchy already exist in OS X when you bind mount it into your container? Does the path you are mounting have symlinks as any of the components? There is a known issue with bind mounts through symlinks that we have a patch for which should arrive in Beta 7.

If you aren’t watching through symlinks, we’ll need to dig deeper.

Thanks for participating in the Docker for Mac Beta!


I seem to be having this problem too, except that I’m on beta 14. Here’s my diagnostic info:

Docker for Mac: version: v1.11.1-beta14.5.m
OS X: version 10.11.5 (build: 15F34)
logs: /tmp/20160607-215800.tar.gz
failure: No error was detected
[OK] docker-cli
[OK] app
[OK] menubar
[OK] virtualization
[OK] system
[OK] osxfs
[OK] db
[OK] slirp
[OK] moby-console
[OK] logs
[OK] vmnetd
[OK] env
[OK] moby
[OK] driver.amd64-linux

I’m working on this project:

Any help would be appreciated :slight_smile:

Could you please post your unique error report identifier? It will enable me to pull your system logs from our repository to get an idea of what has gone wrong.

There is a known issue regarding event delivery failure. In particular, the path used to register for OS X file system events is not properly normalized. You could try restarting Docker and then using paths that 1.) don’t have symlinks 2.) have case matching the case stored in the OS X file system 3.) don’t contain ., .., or a trailing slash /.

We hope to have this known issue resolved soon.

Thanks for participating in the Docker for Mac Beta!

Thanks for the fast response.

Not sure if this is what you meant, but my diagnostic id is: 804F32D7-E6B8-4F1C-8CF0-7DA0F5B9202A. I’m not seeing a specific error, just that webpack --watch isn’t picking up filesystem events.

I just tried restarting docker and changing the casing (on OSX the project is saved as PaperBadger, and docker-compose.yml is configured to paperbadger). But that doesn’t seem to have fixed it. I’m fairly certain that no symlinks or filenames with those character are being used.

I have this same problem as well: webpack --watch does not detect changed files.

However, my Django app running in a different container does reload when files change. I think Django uses some kind of polling technique.

This is quite annoying because now I have to manually touch files from within the webpack container in order to get the compilation to start :weary:

Seeing this as well.

I have verified that inotify is working via inotifywait -r -m . from inside the container and then editing a file on the host (OSX). The changes are picked up right away.

If I run webpack --watch or other webpack variants from inside the container and edit the same mounted file, the changes are not picked up. I have tried with Chokidar which looks like the underpinning library that webpack uses and that doesn’t seem to be working either.

This on 1.12.0-rc2-beta16.

I used this option below to get webpack pickup changes:

watchOptions: {
    poll: true

It works, but it seems to eat up all of the CPU and also the recompilation is slowed down (from 1s before to 5-6s now). Before I was using dinghy with unfs3.