13

I've been working with Docker for Windows, attempting to create a Windows Container that can run cygwin as the shell within the container itself. I haven't had any luck getting this going yet. Here's the Dockerfile that I've been messing with.

# escape=`
FROM microsoft/windowsservercore

SHELL ["powershell", "-command"]

RUN Invoke-WebRequest https://chocolatey.org/install.ps1 -UseBasicParsing | Invoke-Expression
RUN choco install cygwin -y
RUN refreshenv
RUN [Environment]::SetEnvironmentVariable('Path', $env:Path + ';C:\tools\cygwin\bin', [EnvironmentVariableTarget]::Machine)

I've tried setting the ENTRYPOINT and CMD to try and get into cygwin, but neither seems to do anything. I've also attached to the container with docker run -it and fired off the cygwin command to get into the shell, but it doesn't appear to do anything. I don't get an error, it just returns to the command prompt as if nothing happened.

Is it possible to run another shell in the Windows Container, or am I just doing something incorrectly?

Thanks!

mumford
  • 161
  • 1
  • 4
  • 1
    There seems to be a whole category of binaries that do not run in Windows docker containers (exiting silently). Cygwin binaries are an example. 64 bit is not the issue since it happens on both nanoserver and windowsservercore. If anyone knows what the deal is, chime in. – Akom Aug 08 '18 at 16:13
  • @Akom any idea/progress on this? got the same problem, the container just crashes – Żubrówka Sep 03 '18 at 13:39
  • I will open a bounty on this as this is an important topic to address - quite relevant in a DevOps context – Żubrówka Sep 04 '18 at 07:56
  • @Żubrówka I have edited my answer: no conclusive progress, except for a possible workaround. – VonC Sep 04 '18 at 11:22
  • @Żubrówka, I didn't see crashing containers, it's the executables that fail to run in containers. I've gotten nowhere with this. I saw a few tickets open with similar symptoms but didn't find an explanation. – Akom Sep 04 '18 at 18:44
  • Check my answer, I managed to get things working for me – Żubrówka Sep 11 '18 at 10:08

3 Answers3

3

You don't "attach" to a container with docker run: you start a container with it.

In your case, as seen here, docker run -it is the right approach.

You can try as an entry point using c:\cygwin\bin\bash, as seen in this issue.

As commented in issue 32330:

Don't get me wrong, cygwin should work in Docker Windows containers.

But, it's also a little paradoxical that containers were painstakingly wrought into Windows, modeled on containers on Linux, only for people to then want to run Linux-utils in these newly minted Docker Windows containers...

That same issue is still unresolved, with new case seen in May and June 2018:

We have an environment that compiles with Visual Studio but still we want to use git and some very useful commands taken from linux.
Also we use of-the-shelve utilities (e.g. git-repo) that uses linux commands (e.g. curl, grep,...)

Some builds require Cygwin like ICU (a cross-platform Unicode based globalization library), and worst: our builds require building it from source.

You can see an example of a crash in MSYS2-packages issue 1239:

Step 5/5 : RUN "C:\\msys64\\usr\\bin\\ls.exe"
 ---> Running in 5d7867a1f8da
The command 'cmd /S /C "C:\\msys64\\usr\\bin\\ls.exe"' returned a non-zero code: 3221225794

This can get more information on the crash:

PS C:\msys64\usr\bin> 
  Get-EventLog -Index 28,29,30 -LogName "Application" | Format-List -Property *

The workaround was:

PS > xcopy /S C:\Git C:\Git_Copy
PS > C:\Git_Copy\usr\bin\sh.exe --version > v.txt
PS > type v.txt

As mentioned in that thread, the output gets lost somewhere in the container, thus sending it to a text file.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
3

After playing with it for a long time, my findings were the following:

  • If your Cygwin utilities are crashing your container, you need to use process isolation. See https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility for the requirements (essentially you need to use Windows Server 2016 and a build-matching Docker Image). I spent some time trying to understand the reason why hyper-v isolation doesn't work and so far I didn't come to any conclusion;

  • If your Cygwin utilities apparently do nothing - but they don't crash the container - you need to remove the -t flag (the -i flag is still ok) or alternatively play with stdout redirection. Apparently there seems to be an issue with MSYS2 when it deals with some pseudo-ttys. You can verify that programs still run if you redirect stdout to a file (e.g. whoami won't output anything when you run it without any stdout redirection, but whoami > out.txt will output the expected result to a file). It might be possible to fix this by replacing the pseudo-tty but I didn't try it. I suspect that the problem is an invalid handle somewhere inside the MSYS2 libs - as other console apps can print things to the terminal - but I didn't verify this.

Hope it helps to all of you having the same problem.

Żubrówka
  • 730
  • 1
  • 10
  • 24
2

I was able to get a preinstalled (copied from the host) copy of Cygwin to work in a nanoserver-based container with these two steps:

  1. Using Żubrówka's recommendation for no -t in the docker run cmd-line (when running docker interactively)
  2. Copying the host's (Windows Server 2016) kernel32.dll to the container's c:\windows\system32

I found serveral versions of kernel32.dll on my system, and used the one from c:\windows\system32 with md5 hash d8948a7af764f7153b3e396ad44992ff

This also made a large variety of other executables work. Note that without a tty, using the container is even more cumbersome, and the bash shell doesn't render the prompt. However, scripts (via Jenkins, in my case) that rely on cygwin components work fine.

If that doesn't help, try this guide, it helped me a lot. If your windows application (other than cygwin) is legitimately missing DLLs, the instructions in this guide can help. It never occurred to me that SysInternals' procmon.exe can be run on the host and still report events from the container!

Akom
  • 1,484
  • 19
  • 25