Unable to run cygwin in Windows Docker Container - windows

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!

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.

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.

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:
Using Żubrówka's recommendation for no -t in the docker run cmd-line (when running docker interactively)
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!

Related

Running wsl results in starting a Jupyter Notebook

I have installed Anaconda under Windows and Ubuntu under WSL. I have not used this Ubuntu installation for a long time. When I tried to run Ubuntu now, I saw the following:
That is, WSL starts a Jupyter Notebook server, which I have to kill by hitting Ctrl-C to get the Ubuntu prompt. What could be causing this behavior?
There are several ways for something to "autostart" when running WSL:
First, you (or an application) may have modified your startup scripts to start the Jupyter Notebook server. To see if this is the case, try starting WSL from PowerShell by running:
wsl -e bash --noprofile --norc
This will run bash without the startup scripts. If this brings you to the prompt without running the notebook sesrver, then the problem is in your ~/.bashrc or ~/.bash_profile (assuming bash is your default shell).
Given the symptoms you are seeing, this is the most likely cause. If that's the case, look in those files to see if you can find the line that is starting the server, and comment it out.
Second, and related to the first, do you recall trying to enable Systemd at any point using something like Genie or WSL2Hacks? If so, then I believe they modify your start scripts to run Systemd, which can be used to start other services. However, I would expect those Systemd-executed services to start daemonized, in the background, and not interrupt your shell's startup.
Under Windows 11, services can also be autostarted via /etc/wsl.conf, but again, they would be started by the root user in this case, and in the background. I can't think of a non-pathological way that this could be used to interrupt the user's startup shell experience.

What is the easiest way to run bash dependent dockerfiles on windows?

I need to setup docker on my windows 10 OS. I've previously been a linux guy where everything just works so this is a pain for me. It works as expected but within the dockerfile there are calls that uses /bin/bash which makes the build fail.
I've tried to setup a VM with hyper-v but then i stopped because i figured there must be an easier way. I found the bash.exe in windows. i can't run as sudo but i guess that doesn't matter here as long as i run bash as administrator. wget works here but the docker program cant be found when i run docker --version.
Is the easiest way to run bash scripts on win10 with the bash.exe? And why can't docker run in the bash terminal (there is no .bashrc)?
I would use Linux on the Windows box. The two systems can access each other's file systems (\\wsl$, /mnt/c). I use Ubuntu, and it's as if I was using a "normal" Ubuntu box in all aspects, so far. I'd be surprised if your process didn't work here.
Alternatively, there's Cygwin. When running Cygwin, you're kinda in a VM, kinda not. It's a bit blurry. As such, it's not as robust as WSL. But it might do the trick, and it's a lot less "heavy" than installing a full Linux distro.

Laravel installation sail problem ((23) Failed writing body)

I try to install laravel with the original laravel document but nothing happened, I got many errors, for example I tried this command on CMD;
curl -s https://laravel.build/example-app | bash
but I got this error
(23) Failed writing body
When I tried with PowerShell I got this error;
cmdlet Invoke-WebRequest at command pipeline position 1
Supply values for the following parameters:
Uri:
curl : Cannot find drive. A drive with the name 'https' does not exist.
At line:1 char:1
curl -s https://laravel.build/example-app | bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo : ObjectNotFound: (https:String) [Invoke-WebRequest], DriveNotFoundException
FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
Specs;
Docker Engine v20.10.0
Edition Windows 10 Home Version 20H2 Installed on ‎14/‎08/‎2020 OS
build 19042.685 Experience Windows Feature Experience Pack
120.2212.551.0
I ran into this issue as well and found the (usually excellent) Laravel documentation to be a little vague.
First of all, I have some knowledge of Docker but wanted to get much better acquainted so the recent release of Laravel Sail seemed like an excellent starting point.
Install Docker Desktop https://docs.docker.com/docker-for-windows/install/
Install and enable WSL2 https://learn.microsoft.com/en-us/windows/wsl/install-win10#simplified-installation-for-windows-insiders
The Laravel docs mention this in above step but the part I missed was installing a Linux distribution at the same time (via the Microsoft Store). I assumed Sail took care of this part.
Goto the windows store a get your distro e.g. Ubuntu 20.04 (https://www.microsoft.com/en-gb/p/ubuntu-2004-lts/9n6svws3rx71?rtc=1)
Install Windows Terminal - https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk701?rtc=1&activetab=pivot:overviewtab. Up until now, I was using Cmder or ConEmu rather than the Command Prompt. The important difference is you can start a new shell for windows or any of the Linux distributions you have installed. Again, I assumed you could use the curl -s https://laravel.build/example-app | bash command in my windows Cmder - not the case.
Start up a new Linux shell and if you ls you'll see your Windows filesystem. From there I cd'd to my projects directory, ran curl -s https://laravel.build/example-app | bash and that took care of the rest.
One caveat is that you may have to enable any downloaded Linux distributions in Docker:
Of course, the process makes sense when you solve it and Sail does offer some useful shortcuts in getting a Laravel project up and running quickly with Docker but complete newcomers could be forgiven for thinking it takes care of absolutely everything - which it doesn't.
Side note
The reason you were getting the error in PowerShell is because PS has an alias for curl but not the curl you expect. (cURL in power shell windows 8.1: "A drive with the name 'localhost' does not exist")
You can permanently remove this (https://github.com/lukesampson/scoop/issues/56#issuecomment-609098474) but you may not need to now you know how to use the command in your Linux shell.
The solution above provided by #chris-j works like a charm, but if you still get the error "Docker in not running" even if the it's green consider doing the following
Do sudo su and then curl -s https://laravel.build/example-app | bash

stata-se, xstata-se command not found

I can't open the GUI of Stata running on local macOS machine from remote Ubuntu server.
I have installed stata-se on my local machine, I can open X11 apps like xclock and xeyes. I'm using the following command to connect to the server:
ssh -X username#servername -p XXXX
Is there any to resolve this issue?
Since the distinction is a little unclear in the question:
According to the documentation the command to launch the Stata SE GUI is:
xstata-se
while
stata-se
launches the console version.
Since these are not working you can confirm the syntax diagram with:
stata -h
which will tell you the correct syntax, if Stata is actually installed.
If you are seeing something like:
$ command not found: Stata
then you may, similar to this, need to make sure that the path to Stata is properly set in your path file. Exactly how you do this depends on your terminal and operating system.

Specifying JupyterHub Path Variable

I am in the process of installing jupyterhub. I successfully install jupyterhub using:
python3 -m pip install jupyterhub
npm install -g configurable-http-proxy
However, when I run jupyterhub -h in the Windows command prompt it gives:
"jupyterhub" is not recognized as an internal or external command, operable
program or batch file.
I added C:\Users\User\AppData\Local\Continuum\Anaconda3\Lib\site-packages\jupyterhub\ to my user environment variable, however still receive the message. What path should I be using?
Please note that according to this, Jupyterhub is not officially supported for Windows yet.
That aside, you could dockerize it to make your life easier. For this error, please check if you can see the executable in C:\Program Files\Continuum Analytics\Anaconda3\scripts. The lib directory you're specifying contains python source files and not the executables.
I had this same issue, and I saw this occurred because jupyterhub is a python script rather than an executable. So to run this on Windows I needed to execute it like python C:\Program Files\Continuum Analytics\Anaconda3\scripts\jupyterhub.
However, I still was unable to run jupyterhub on Windows because it depends on the pwd module, which is a Unix/Linux only module.
As others have said, Windows is not a supported platform. JupyterHub is best used on Linux-like platforms where you have Docker or something similar to conatainerize each user's session.
A good alternative is to install Oracle VirtualBox and run a local VM. I run a 64-bit Ubuntu and it's quite good performance. It makes things much easier to run JupyterHub on. Asides depending on pwd, there are also assumptions around user-creation and other activities that Windows isn't going to handle well.
In short, if you want to run on native Windows, you're going to become the first JupyterHub Windows contributor. I looked at doing it but it looked like too much effort.
The upside of running a VM is that behaviour in the VM is going to more closely resemble what you have running on the server anyway. If you don't plan running on a server, then just "jupyter notebook", as this is all JupyterHub ends up running...

Resources