Docker-sync: Windows: docker-sync >= 0.5.8 unison-fsmonitor installed not using brew

[boris-brtan]

Error/Feature Requestion/Docs

Error/Docs
during docker-sync start, there are some prompts that doesn't work and it asks for brew installation

docker-sync start
sh: 1: brew: not found
     warning  You installed unison-fsmonitor (unox) the old legacy way (i.e. not using brew). We need to fix that.
Uninstall legacy unison-fsmonitor (unox)? (y/N) y
     command  sudo rm -f /usr/local/bin/unison-fsmonitor
     warning  Could not find eugenmayer/dockersync/unox. Trying to install it now.
Install eugenmayer/dockersync/unox for you? [y/N] y
     command  apt-get install -y eugenmayer/dockersync/unox
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
       error  shopsys-framework-sync has been configured to sync with unison, but no unison available
       error  Failed to install required package. Please install it manually and try again.

Is there way how to install brew in WSL with functional unison-fsmonitor ?

Docker Driver

Windows docker 18.06.1-ce

Sync strategy

unison

your docker-sync.yml

based on Wiki

OS

Windows 10 Pro 1803

[EugenMayer]

now brew should not get used in a windows env, thats rather a bug. fsmonitor is a osx only thing AFAIR

Feel free to investigate/PR, usually there is rather less focus on the windows branch of the core team, so if you do want to speed this up / help, i would be happy!

[boris-brtan]

now brew should not get used in a windows env, thats rather a bug. fsmonitor is a osx only thing AFAIR

Feel free to investigate/PR, usually there is rather less focus on the windows branch of the core team, so if you do want to speed this up / help, i would be happy!

Ok, i will try to get into ruby and maybe i would be able to create some PR. Maybe just here maybe in https://github.com/bcpierce00/unison/

[Jarzebowsky]

@EugenMayer so maybe it will be easier to remove support at all for Windows cuz it's unusable at all. In previous job I had it setup and worked like a charm, after migrating to new one it just don't work and return bunch of errors. That's sad 'cause you were only one that worked that good on Docker on Windows...

[EugenMayer]

Well @Jarzebowsky what about stepping in and helping, not just expecting me to either fix it or remove it? :)

I do not use windows and i have enough duty with keeping the support up for MacOS which is my main branch - support for windows was experimental and the one implemented opted in with long time support .. well i guess that is no longer the case. Most people seem to go straight from windows to linux due to that issue, but well, that's not an option for all.

All i am saying, i am transparent what i plan to work on, and what i am not. I'am very happy though if people contribute and merging / discussing PR's.

[boris-brtan]

That's why i am now trying to get into the problematics and solve the problems for Windows.

[Jarzebowsky]

@EugenMayer I would if there is something I'm good at and up to - guess.. I'm not and that's the main point of that I can't contribute, following one is lack of time to even get into it to fix it.

@boris-brtan I'm looking forward for your PR which will make it stunning again.

[jakubwol]

It seems to be working fine in version 0.5.7 - I've added a note about it in the Wiki.

[EugenMayer]

since like either the OSX detection is broken or something else i changed with 0.5.9 - anybody digged deeper into that ?

[boris-brtan]

or it didn't work at all. since old version flushed errors brew list unox &> /dev/null like i think it does mean.
And another thing i tried to use functionality of DOCKER_SYNC_SKIP_DEPENDENCIES_CHECK but it somehow doesn't work and it still reaches somehow the part for checking ensure_all_for_mac and problematic UNISON.ensure

[EugenMayer]

can someone confirm that
pgrep -q com.docker.hyperkit is a $? = 0 under windows? i think that is the bug we are hunting after all

the changed most probably causing this is https://github.com/EugenMayer/docker-sync/blob/master/lib/docker-sync/dependencies/docker_driver.rb#L8

https://github.com/EugenMayer/docker-sync/commit/772075b2465d9771b6bf523111c945abeecb8f76

[EugenMayer]

also please someone with WSL provide the exit codes for

ps aux | grep com.docker.hyperkit | grep docker-for-mac -q

and

ps aux | grep com.docker.hyperkit | grep docker-for-windows -q

and the output of

ps aux | grep com.docker.hyperkit

You can strip any sensible part but please leave all the generic parts in place

[EugenMayer]

i ned the exit codes for each.

after each command do echo $?

[boris-brtan]

WSL

user@DESKTOP-P99P4BT:/c/Users/user$ ps aux | grep com.docker.hyperkit | grep docker-for-mac -q
user@DESKTOP-P99P4BT:/c/Users/user$ echo $?
1
user@DESKTOP-P99P4BT:/c/Users/user$ ps aux | grep com.docker.hyperkit | grep docker-for-windows -q
user@DESKTOP-P99P4BT:/c/Users/user$ echo $?
1
user@DESKTOP-P99P4BT:/c/Users/user$ ps aux | grep com.docker.hyperkit
user 141  0.0  0.0  14804  1220 pts/0    S    16:32   0:00 grep --color=auto com.docker.hyperkit
user@DESKTOP-P99P4BT:/c/Users/user$ echo $?
0

[EugenMayer]

could you also test pgrep -q com.docker.hyperkit

[boris-brtan]

it is 2 because pgrep doesn't have q option on debian installation for windows

 pgrep -q com.docker.hyperkit
pgrep: invalid option -- 'q'

Usage:
 pgrep [options] <pattern>

Options:
 -d, --delimiter <string>  specify output delimiter
 -l, --list-name           list PID and process name
 -a, --list-full           list PID and full command line
 -v, --inverse             negates the matching
 -w, --lightweight         list all TID
 -c, --count               count of matching processes
 -f, --full                use full process name to match
 -g, --pgroup <PGID,...>   match listed process group IDs
 -G, --group <GID,...>     match real group IDs
 -i, --ignore-case         match case insensitively
 -n, --newest              select most recently started
 -o, --oldest              select least recently started
 -P, --parent <PPID,...>   match only child processes of the given parent
 -s, --session <SID,...>   match session IDs
 -t, --terminal <tty,...>  match by controlling terminal
 -u, --euid <ID,...>       match by effective IDs
 -U, --uid <ID,...>        match by real IDs
 -x, --exact               match exactly with the command name
 -F, --pidfile <file>      read PIDs from file
 -L, --logpidfile          fail if PID file is not locked
 --ns <PID>                match the processes that belong to the same
                           namespace as <pid>
 --nslist <ns,...>         list which namespaces will be considered for
                           the --ns option.
                           Available namespaces: ipc, mnt, net, pid, user, uts

 -h, --help     display this help and exit
 -V, --version  output version information and exit

For more details see pgrep(1).

[EugenMayer]

seems like this is not what cause the issue, thanks for providing the information. It's right now very hard for me to "far guess" what could be just wrong right now without having a Windows WSL.

Since all the contributors of the WSL project seem to either have lost interest ( moved to a different os ) or just have no time contributing i am right now really considering closing down the support since i cannot support it.

I would love to see someone volunteer here, but right now it seems unlikely

[boris-brtan]

hi, i think that you dont need to have WSL. It should be the same as to have linux distro, also you are able to do test on travis if you use debian image or ubuntu image with the Dockerfile that install all the tools from the guide.

docker run -it debian bash

If you want i could create Dockerfile with all of that and you can just run it with docker. It should be the same principle as with docker on mac since there will be docker that connects to main docker service.

[EugenMayer]

No, that wont work, because the docker-engine is exposed differently under docker-for-windows then the native docker-engine under linux. I understand, that we are talking about a ubuntu running docker, but as under macos, its a virtualized linux kernel and that changes up things a lot, especially on the docker 4 X part.

Generally, docker-4-windows is a linux running docker - no doubt.
But its not a "linux running docker"

If you can test this and create a dockerfile where you see the same process structure, process names as under windows WSL, that would be a huge help for sure - but i rather doubt it. Please prove me wrong ! :)

[boris-brtan]

sorry for the delay but i needed to do some work on GoogleCloud. This weekend i could have some spare time so i will try something like https://travis-ci.org/jborean93/travis-ci-win-ansible/jobs/447023999/config
or if you are better in travis configuration please try something on your own.

[boris-brtan]

for now you can skip support for windows in new versions, i need some time to learn more about the tools it uses. i don't want to block new releases.

[EugenMayer]

@boris-brtan thank you for the feedback!

[Jarzebowsky]

The best thing would be wait till WSL provide native support of Docker and Docker Compose inside it - which is coming in near future.

[RonMelkhior]

The best thing would be wait till WSL provide native support of Docker and Docker Compose inside it - which is coming in near future.

Interesting, sorry for going off-topic, but can you link the announcement for this? I can't find anything about it.

[Jarzebowsky]

The best thing would be wait till WSL provide native support of Docker and Docker Compose inside it - which is coming in near future.

Interesting, sorry for going off-topic, but can you link the announcement for this? I can't find anything about it.

Sure, here it is
https://github.com/Microsoft/WSL/issues/2291#issuecomment-438388987

[zangai]

I am an Windows developer, and I rely heavily on docker-sync for my development workflow. Therefore I would gladly be able to help with keeping the windows version supported. I am however not yet sure where I should start with looking at this issue.
From the comments on this thread I get the impression that the logic which determines the platform docker-sync runs on was depending on some sort of setting which has been changed now?

[EugenMayer]

to be fank, you nailed it. I was yet not able to find where, but that is the exact issue

[EugenMayer]

I think the core issue is, that ds considers WSL to be MacOS and tries to use macOS tools to e. g. install unison. windows should behave like a Linux with WSL in ds, but maybe the Linux detection is faulty and falls back to macOS.. that was basically my last hint

[boris-brtan]

could we start with some matrix extension for travis?
to test it on Linux, osx, windows Wsl ?
https://travis-ci.org/boris-brtan/test-travis-os/builds/483328068/config

[EugenMayer]

We have those tests already - though they are not working right now (the tests themselfs are broken) https://github.com/EugenMayer/docker-sync/issues/605 .. this could even be related to this issue

[EugenMayer]

i just released a 0.5.10-beta1 - could you verify this fixes your issue? https://rubygems.org/gems/docker-sync/versions/0.5.10.pre.beta1

[jakubwol]

I've just updated docker-sync from 0.5.7 to 0.5.10-beta1, and it seems the issue is fixed - it started without any problem.

[EugenMayer]

Hello guys, due to a regression bug with 0.5.10 for mac users, there is a new fix to that issue which might affect this one

Please test-install 0.5.11-beta1 (windows/linux users) and tell me if it works for you. Thanks

[ignatiusreza]

@EugenMayer tested 0.5.11-beta1 with some of the docker-sync-boilerplate in ubuntu, and seems to be working..

[mferrier]

Same issue with 0.5.11.pre.beta2:

/Users/mferrier/.rbenv/versions/2.3.7/lib/ruby/gems/2.3.0/gems/docker-sync-0.5.11.pre.beta2/lib/docker-sync/upgrade_check.rb:59:in `check_and_warn': undefined method `check_unison_image' for #<UpdateChecker:0x00007f9d3117a270> (NoMethodError)
Did you mean?  check_rsync_image

[EugenMayer]

@mferrier could you open a new ticket with your configuration including?