githubnemo / CompileDaemon

Very simple compile daemon for Go
BSD 2-Clause "Simplified" License
1.61k stars 153 forks source link

Change events not triggered in Docker after a while #44

Closed yuraxdrumz closed 3 years ago

yuraxdrumz commented 4 years ago

I have a local docker-compose setup with 10+ services, where each of them is built and run by CompileDaemon. Each service's local go folder is mounted as a volume to allow the developers at my company to make changes and CompileDaemon takes care of restarting the go server when any source file is changed.

Expected Behavior

All the services should restart after a file has changed

Problem

After several restarts with 10+ services, restarts with CompileDaemon stops working without any errors and I have to manually restart the container or restart the docker daemon for the notify events to work again.

Environement

MacOS Catalina 10.15.2 (19C57) Docker Desktop 2.2.0.3 (42716) Engine Version 19.03.5 Compose Version 1.25.4

Example Dockerfile Entrypoint

ENTRYPOINT CompileDaemon \
    --build="go build -o my_service" \
    -exclude-dir=.git -exclude=".#*" \
    --command="./my_service"

Example Folder Mounting in Docker Compose

  my_service:
    build:
      context: .
      dockerfile: ./my_service.Dockerfile
    volumes:
      - $GOPATH/src/bitbucket.org/xxx/my_service:/go/src/bitbucket.org/xxx/my_service

Suggested Solution

If, after a thorough research we find that the problem is deeper then a few config files, maybe we can write a polling mechanism and watch for changes ourselves and ditch the inotify features. It is not the best solution but it will be a nice workaround if people just want things to work.

mingrammer commented 3 years ago

I have the same issue.

githubnemo commented 3 years ago

Thanks to @HurSungYun, CompileDaemon now supports -polling=true which switches from FS notifications to active polling for changes. While this is neither instant (notifications are delayed by the polling rate) nor resource friendly (always looking instead of being event driven) it is a workaround to help get people back to work. I strongly discourage you from using this in any production environment.