Docker-sync: Rsync container does not start after restart: "pidfile exsits with pid 19, killing and removing it - restarting further on" and "error Error starting sync, exit code 10"

[motin]

Our current setup works fine right after docker-sync clean and subsequent docker-sync-stack start. The rsync container logs also report a successful start:

user with uid 0 already exist and its root
/entrypoint.sh: ignoring /docker-entrypoint.d/*
/usr/lib/python2.7/site-packages/supervisor/options.py:296: UserWarning: Supervisord is running as root and it is searching for its configuration file in default locations (including its current working directory); you probably want to specify a "-c" argument specifying an absolute path to a configuration file for improved security.
  'Supervisord is running as root and it is searching '
2018-03-13 09:33:59,105 CRIT Supervisor running as root (no user in config file)
2018-03-13 09:33:59,105 WARN Included extra file "/etc/supervisor.conf.d/supervisor.daemon.conf" during parsing
2018-03-13 09:33:59,141 INFO RPC interface 'supervisor' initialized
2018-03-13 09:33:59,142 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2018-03-13 09:33:59,143 INFO supervisord started with pid 1
2018-03-13 09:34:00,148 INFO spawned: 'rsync' with pid 19
2018-03-13 09:34:01,989 INFO success: rsync entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

After a restart (either a stack / Docker / computer restart) docker-sync will seem to start up fine, but rsync will not work, complaining about error Error starting sync, exit code 10 in the logs.

The rsync container logs shows that it did not start successfully:

user with uid 0 already exist and its root
/entrypoint.sh: ignoring /docker-entrypoint.d/*
pidfile exsits with pid 19, killing and removing it - restarting further on

A workaround is to start rsync manually in another terminal window (any time after docker-sync has started complaining about not being able to start rsync)

docker run -it -v sq-personal-unit-sync-app:/app_sync -e VOLUME="/app_sync" -p 10873:873 eugenmayer/rsync supervisord

After changing a file, the sync will be attempted again and this time it completes successfully as long as the new rsync container is running.

Docker Driver

d4m - Version 17.12.0-ce-mac55 (23011)

Sync strategy

A combination of rsync + unison (albeit only the rsync is failing - unison works fine most of the time)
Using docker-sync 0.5.4 (the problem also existed in 0.5.2)

docker-sync.yml

version: "2"

options:
  verbose: false
syncs:

  # one-way sync using rsync by default for performance reasons
  sq-personal-unit-sync-app:
    src: './' # VERY important with a trailing slash, since otherwise the host sync root gets synced to /app/personal-unit instead of /app
    sync_host_ip: 'auto'
    sync_host_port: 10873
    sync_strategy: 'rsync'
    sync_args: '-v --progress --safe-links --delete --no-perms'
    sync_excludes: [
      '.git',
      '/.files',
      '/stack/localdb',
      '/src-images-build',
      '/ui',
      '/tools/code-generator',
      '/dna/generated-classes',
      '/dna/generated-migrations',
      '/dna/generated-reversed-database',
      '/dna/generated-sql',
      '/dna/db',
      '/dna/tests/codeception',
      '/external-apis/rest-api-dna',
      '/tmp',
      '/deployments'
    ]

  # two-way syncs only where new files and contents are expected to be created within the container:
  sq-personal-unit-sync-app-dna-generated-classes:
    src: './dna/generated-classes'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-dna-generated-migrations:
    src: './dna/generated-migrations'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-dna-generated-reversed-database:
    src: './dna/generated-reversed-database'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-dna-generated-sql:
    src: './dna/generated-sql'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-dna-db:
    src: './dna/db'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-dna-tests-codeception: # for _data, _log, _tmp and _helpers/_generated
    src: './dna/tests/codeception'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-external-apis-rest-api-dna:
    src: './external-apis/rest-api-dna'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-tmp:
    src: './tmp'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']
  sq-personal-unit-sync-app-deployments:
    src: './deployments'
    sync_strategy: 'native_osx' # not needed, this is the default now, but including for clarity
    sync_excludes: ['.git']

OS

OSX High Sierra 10.13.3 (17D102)

Other

Please don't close this issue until it is solved. I know from other issues that there is hardly anybody working on anything else then native_osx, but using native_osx is not an alternative for us due to performance issues with large codebases. Maybe there are some others using rsync out there that have a similar problem. In case docker-sync maintainers won't fix this, please still let this issue be open until we (as a community) have found a solution. Thanks :)

[EugenMayer]

@motin thanks for explainin in "Other" - i am not going to close this at all as long as there is a realisation that nobody is right now working on this actively and people need to step in if they want to see that fixed.

Though, if roughly 2-3 months, no movement is tracked, i would then close this issue considering this a ghost or "not enough interest exists".

I will of course consider every PR and help if any questions are, i am not blocking this at all. But an issue queue with 50% issues nobody looks at / ignores and are oben for ~6 months is not helping anybody either i guess.

Thanks for the detailed analysis!

[EugenMayer]

closing this due to no progress, reopen if you want continue working on it