Skip to content
This repository was archived by the owner on Aug 29, 2022. It is now read-only.

SYNC_PREFER defaults back to /source after Docker restart #13

Open
normanlolx opened this issue Feb 5, 2018 · 1 comment
Open

SYNC_PREFER defaults back to /source after Docker restart #13

normanlolx opened this issue Feb 5, 2018 · 1 comment

Comments

@normanlolx
Copy link
Contributor

normanlolx commented Feb 5, 2018

Taking the basic docker-compose.yml from the README but SYNC_PREFER: newer and restart: always set. Everything works fine except after you restart the Docker for Mac app (or restart you Mac). From then on the sync is unidirectional again as if SYNC_PREFER=newer never was set.

Steps to reproduce:

  1. $ git clone https://gist.github.com/leymannx/5d27bd6f0f0b08b13e58baa4bcd866ae.git bg-sync
  2. $ cd bg-sync
  3. $ docker-compose up -d (wait until done)
  4. $ touch hello.txt
  5. $ docker exec -it -w /var/www/myapp bgsync_web_1 bash -c "touch world.txt"
  6. Confirm both files exist in both locations:
    1. $ ls
    2. $ docker exec -it -w /var/www/myapp bgsync_web_1 bash -c "ls"

Restart Docker for Mac app (or restart Mac).

  1. Again inside the bg-sync folder from step 1. on the host: $ touch alpha.txt
  2. $ docker exec -it -w /var/www/myapp bgsync_web_1 bash -c "touch beta.txt"
  3. Confirm there's no alpha.txt in the container:
    1. $ ls
    2. $ docker exec -it -w /var/www/myapp bgsync_web_1 bash -c "ls"

macOS 10.13.3
Docker for Mac (stable) 17.12.0-ce-mac49 (21995)

Workaround is to simply leave restart: always out and/or always (re-)start the containers manually $ docker-compose start.

Although the Dockerfile and the sync script is kept brilliantly small I don't have a clue how to fix this.

normanlolx added a commit to normanlolx/dockerix that referenced this issue Feb 5, 2018
@dj95
Copy link

dj95 commented Feb 19, 2018

It doesn't default back to SYNC_PREFER=newer. Please check the environment-variables in your sync-container with docker exec -it -w /var/www/myapp bgsync_bg-sync_1 env and the unison config file with docker exec -it -w /root/.unison bgsync_bg-sync_1 cat default.prf.

I think it is a problem with docker on macOS(and maybe Windows?) in general, not only with docker bg-sync. Under Linux this issue doesn't exist. Unison triggers on inotify events. If you measure inotify events with the following procedure, you will see, that those are not occuring, if a file is created on the host side of the source-volume after restarting the docker host and starting the containers with their restart: always behaviour.

1.) Get the docker-bg-sync container in the state where it doesnt sync from the host, like @leymannx described in his issue.

2.) Start the inotifywatcher with docker exec -ti bgsync_bg-sync_1 inotifywatch -r /source/

3.) Create a file on your docker host machine in the folder, that is mounted to /source

4.) Ctrl-C to exit the inotifywatcher and display it stats.

5.) Restart docker containers with docker-compose stop and docker-compose up -d

6.) Start the inotifywatcher in the bg-container again

7.) Create another file on your docker host machine, like the one before

8.) Ctrl-C to exit the inotifywatcher.

In step 8 you should see at least one inotify event when the file is created. After step 4 you shouldn't be able to see any inotify events in this folder even if the file was created. This explains why unison is not recognizing the recently created file.

After a short research in docker for mac issues on Github I found this one:

docker/for-mac#681

It is exactly the problem, which explains the behaviour of this issue. I tested the inotify propagation and the behaviour of docker-bg-sync after a simple docker-compose restart and it falls back to the state described in this issue. So I think we need to wait for a fix from the docker team.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants