Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-sync start when already started raises an exception #695

Closed
anlek opened this issue Nov 7, 2019 · 7 comments
Closed

docker-sync start when already started raises an exception #695

anlek opened this issue Nov 7, 2019 · 7 comments
Milestone

Comments

@anlek
Copy link

anlek commented Nov 7, 2019

Error

When you run docker-sync start and the sync is already running, you get an error:

tasks/sync/sync.thor:159:in `daemonize': undefined method `empty?' for nil:NilClass (NoMethodError)

image

In the earlier version, if you called docker-sync start when it was already running, it would respond with "Sync already running" (or something like that).

docker-sync version

0.5.13

Docker Driver

N/A

Sync strategy

N/A

your docker-sync.yml

N/A

OS

MacOS 10.14.6

@martmull
Copy link

I have got the same error since this morning

@dimonixx
Copy link

Me too

@Maxooo
Copy link

Maxooo commented Nov 13, 2019

Same behavior here after the Mac OSX Catalina (10.15.1) update.

Configuration key Value
docker-sync 0.5.13
ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]
docker 2.1.0.4 (Docker Desktop)
Sync strategy native_osx
Mac OSX Catalina 10.15.1

I also noticed some Unison spawn instability with the same configuration (with native_osxstrategy).

➜  docker-sync start
          ok  Starting native_osx for sync monolith-sync
monolith-sync
unison: stopped
unison: ERROR (spawn error)
     success  Sync container started
     success  Starting Docker-Sync in the background

Deconstrained added a commit to Deconstrained/docker-sync that referenced this issue Nov 19, 2019
Despite :sync_name being a string type argument, in Mac OS X / a few versions
of Ruby reported, the argument's value gets interpreted as nil when not given
on the command line.

This sets the default for the argument to an empty string so that when .empty?
is called on it, it won't produce NoMethodError the way it would for nil
@Deconstrained
Copy link
Contributor

Deconstrained commented Nov 19, 2019

I am convinced I have found the cause of the issue:

The value is expected to default to an empty string (ostensibly) but it's coming through as nil for whatever reason.

PR #698 addresses this by explicitly setting a default.

Edit: there were other issues that came up when I set the default explicitly, so I modified my PR to address the specific exception that arose (i.e. check for whether the value is nil first).

@EugenMayer
Copy link
Owner

EugenMayer commented Nov 23, 2019

This makes pretty much sense -this was introduced in the last release and we forgot to care about the proper defaults. Thanks for your effort

EugenMayer added a commit that referenced this issue Nov 23, 2019
@EugenMayer EugenMayer added this to the 0.5.14 milestone Nov 23, 2019
@Maxooo
Copy link

Maxooo commented Nov 25, 2019

Thank you @Deconstrained for your work and @EugenMayer for the new v0.5.14 version which works perfectly now. Your investment in this project is well appreciated and makes us win so much time with Docker on Mac every-day. 🙏

@EugenMayer
Copy link
Owner

The main driving force is the community right now, I just take time to coordinate / stuff together. So I forward all the credits to you gents and lads :)

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

No branches or pull requests

6 participants