bind mount inotify events not delivered after container restart #681
Comments
|
Another user reports at https://forums.docker.com/t/docker-for-mac-inotify-events-only-working-from-vim/18772/5 that file saves from |
|
I saw that report about VIM working, but I find even VIM edits are not propagating. |
|
From your issue edition with reproduction, the |
|
ah, I didn't realize close_write wasn't supported. I'll rerun the example with modify. I was simply trying to simplify the case. modify does work. I'll try and build a simple webpack example and see if that repros |
|
after restarting the issue seems to have cleared itself and webpack is able to pick up changes. However several restarts of both docker and the full OS were tried, and the issue has been repeated on multiple machines. I'll continue to try and nail down a solid repro |
|
Same issue here. Restarting breaks docker so I have to restart the computer for it to work. Breaks it so much the diagnostics doesn't even run. |
|
Also seeing similar things on 1.12.1-beta26.1, also with webpack-dev-server. Unable to track things down exactly, but pretty sure this started happening once I installed the new beta update. Restarting my computer doesn't seem to have any affect, and seeing the same behavior regardless of editor (Atom and vim, mainly) I'm using. |
|
@dawnerd could you be more specific about how "restarting break docker"? Are you using the 'restart' button in the menu/preferences? Are you quitting and starting the app again? Do diagnostics work after you restart the machine? What are the symptoms of the broken docker? If diagnostics work, we'd really appreciate it if you could file a new issue with the details of what you did, what happened, and a diagnostic id (it's likely that logs were still being written even when Docker was very broken and this could help us track down the defect). @holman does |
|
@dsheets Would love to provide more info if I could. Used the restart button and the icon showed it had come back up. Clicking Diagnostics didn't load, just an empty window. If logs are dumped on the machine somewhere I could try to look for them. |
|
@dawnerd You can run |
All of it is showing up as |
|
Had a developer encounter the same issue. It went from working to not working without any change in version. our normal setup (which he had working): what he changed: what fixed it: |
|
the afore mentioned "fix" later rendered Docker for Mac completely unusable for him. |
|
I installed the latest beta (1.12.2 rc1 beta 27) running my script, modify events are not being picked up from outside the container. from inside the container modified files are detected as expected |
|
after installing 1.12.0 10871 Even when modifying the file from within the container webpack did not pick up on changes (source files still in the volume mount) I restarted webpack and it started picking up changes from within the container I modified my script to run webpack successfully triggers from changes made outside the container this way (file edits were made using vim/vi) |
|
after installing 1.12.1 (12133) with the same container, I'm not detecting the modify events with the script or webpack just as I saw with 1.12.2 |
|
after completely rebooting my mac I'm able to get inotify modify events from edits made outside the container to be detected with 1.12.1 (12133). No amount of restarting docker / killing the processes worked. Shell script only, webpack still isn't picking up the changes without it running |
|
@genei09 could you please upload your diagnostic logs to our server by running: So that we can investigate your issue. Thanks! |
DOCKER_TLS_HOSTNAME is set to localhost for use with Ansible |
|
the previous diagnostic was run while modify events were being passed through to the container. the following was after seeing the symptom return. |
|
after quitting docker and restarting, and recreating the container the problem persisted. |
|
after restarting the machine the containers were damaged and unusable. When attempting to exec into the containers to see what was going on I receive the message: |
|
after rebuilding the containers the same symptom is present. no longer able to detect modify events from outside the container, and vi only triggers modify events when close/write is used. possibly a kernel issue? |
|
It looks like the containers pick up modify events fine until you issue a I've repeated this 3 times and each time it reacts the same way. |
|
Has this issue been addressed at all? Major blocker. |
|
Same symptoms here. Using |
|
I appear to be able to work around the issue by running another container that bind-mounts the same directory as the broken container and running That's worked twice, anyway. I'll check back here if I find a more consistent repro than that. EDIT: Yep, totally confirmed and consistent. Running an additional container that bind-mounts the same directory fixes the problem in the first container. You don't have to run This feels like a refcount-getting-decremented-too-many-times kinda thing. |
|
I have a coworker who reported that if he had 2 volume's in a container, then only 1 of the volume's would respond to file changes. |
|
Seeing some weird and possibly related stuff; basically containers 'sometimes' picking up file modification events but not always, and it apparently dropping out after a period. |
|
I was able to reproduce this quite easily by running 4 instances of a modified image from the original description and then changing git branches in the bind mounted repos. Details in EugenMayer/docker-sync#410 (comment) Has any progress been made on this? It is currently blocking my team from using Docker for Mac. |
|
I've created a workaround that I figured I'd share here for anyone using Docker Compose. version: '3.5'
services:
my-app: &my-app
image: my-image
depends_on:
- my-app-inotify-fix
volumes:
- .:/code
command: ["my-command"]
my-app-inotify-fix:
<<: *my-app
command: ["tail", "-f", "/dev/null"]
depends_on: []After a ton of tinkering around I was seeing the same results as @iameli. This hack will keep another container running with the same image and volume mounts so inotify events should continue to work even after |
|
After |
|
It'd be really great to see this issue prioritized, it's a huge timesuck when developing having destroy my containers and/or restart Docker itself if that doesn't work. Not to mention the time I spend refreshing pages before realizing Docker's stopped syncing fs changes 😅 |
|
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
|
/remove-lifecycle stale |
|
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
|
/remove-lifecycle stale |
|
/lifecycle frozen |
|
Any update on that? I faced the same problem while running two projects with really huge node_modules folders mapped through volumes. When I comment out one of them in my compose.yml, the other project starts receiving the file events. This observation makes me think that maybe docker daemon hits some limits set on the host machine. |
|
I'm running into this issue, too. Docker Desktop 4.5.0 (74594) with Engine 20.10.12 and Compose 2.2.3 on macOS 10.15.6. It does not matter whether I use gRPC FUSE or legacy osxfs. I run into the problem even after a fresh startup of the docker vm and recreation of all the containers (so not only after a restart). |
and others
Expected behavior
changes to OSx filesystem are picked up by the webpack process
Actual behavior
Even though the files are changed, no change is detected
Using the same docker image in Dinghy produces the expected results
Information
Steps to reproduce the behavior
Dockerfile:
make a shell script inotifyrun and mount that directory as a volume
script:
example docker run command
run the shell script
cd /opt/APP_REPOS./inotifyrun.sh tail test.logusing VIM or other local file editor make a
test.logfile in the mounted dir and see no changestop the shell script
copy to ~/
run the same experiment but exec into the container and use VI to make/modify the file.
the changes are detected and the tail command runs.
The text was updated successfully, but these errors were encountered: