I have a strange situation that i would like to share with you.
I started container recently and wand to have Azure DevOps agent running on container.
On my windows 10 laptop , i can instanciate a Linux container and
everything run & execute well (using WSL)
On a Ubuntu VM running an Azure, the same container run well and
execute well
However the same container in Azure Container instance failed and for unknow reason i get the following error:
Generating browser application bundles (phase: setup)...
/bin/sh: 1: wslpath: not found
01 12 2022 14:55:59.933:ERROR [config]: Error in config file!
Error: Command failed: wslpath -w "/usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin"
/bin/sh: 1: wslpath: not found
When i see wsl i think about Windows Subsystem Linux but i am not sure. I really do not understand why ACI behave like that with that error.
I always thought that container should behave the same wherever it runs. Did you experience it ? Any idea are welcome.
Regards
Related
Steps to reproduce are very easy.
Create a Dockerfile.
My Dockerfile has many more lines, but I have trimmed them so we can focus in the source of the problem.
Said that, these two lines alone (without anything more) show the problem.
FROM microsoft/iis
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $VerbosePreference = 'Continue'; "]
Run docker build . and you get hcsshim::PrepareLayer - failed failed in Win32: Función incorrecta. (0x1).
Windows 10 Pro 1909 (but it happened too in 1903)
Docker version: 2.1.0.5
Engine: 19.03.5
Machine: 0.16.2
I have found the solution to the problem.
Reading all the https://github.com/docker/for-win/issues/3884 bug, some have found a simple solution: rename C:\windows\system32\driver\cbfsconnect2017.sys so it isn't loaded the next boot.
Disabling that driver enables me to do a docker build for the first time in windows containers in almost a year.
In my case Box Sync was the one using that driver.
EDIT: #GustavoTM have found that pCloud raises the same problem.
EDIT2: #VonC have noticed that some people in the issue in GitHub has solved it deleting this other file: C:\Windows\System32\drivers\cbfs6.sys. I haven't tried that, but i put it if it helps others.
The good thing is that I don't need to uninstall Box, but only rename that file.
This is still an issue (still open) with Win10.
Looks like uninstalling cloud storage providers with file system filters like Dropbox, Box, etc. as a workaround is an option for some users.
Deinstall cloud storage providers or virus scanners; if you identify which one is not working please share in https://github.com/docker/for-win/issues/3884
In my case was the problem similar but the file cbfs6.sys was placed somewhere in the rest of uninstalled application Jungle disk, somewhere in the folder c:\Program files\Jungle disk .... It's part of Callback File System signed by EldoS Corporation.
The folder could be rename only and not delete directly. So I could delete its immediately after the PC restart, before running the Docker. So it could be delete during the Docker service restart too.
I'm building an application on AWS EMR using YARN (and Dask) version Hadoop 2.7.3-amzn-1. I'm trying to test various failure scenarios and I'm wanting to simulate a container failure. I can't seem to find an easy way to kill a YARN container - only the whole application. Is there a command-line utility for this?
[root#node1 lillcol]# yarn container -help
20/04/24 15:04:14 INFO client.AHSProxy: Connecting to Application History server at node1/127.0.0.1:10200
usage: container
-help Displays help for all commands.
-list <Application Attempt ID> List containers for application
attempt.
-signal <container ID [signal command]> Signal the container. The
available signal commands are
[OUTPUT_THREAD_DUMP,
GRACEFUL_SHUTDOWN,
FORCEFUL_SHUTDOWN] Default
command is OUTPUT_THREAD_DUMP.
-status <Container ID> Prints the status of the
container.
Through the command yarn container -signal [container-ID] GRACEFUL_SHUTDOWN to achieve.
i've tried and int works,I hope that will be helpful.
YARN has no CLI or REST API that kills a container.
The simplest way to create a container failure is to login to a NodeManager host and kill the process (which would be a container) spawned by the NodeManager.
Seems like it's exposed in API starting from version 2.8.0
https://hadoop.apache.org/docs/r2.8.0/api/org/apache/hadoop/yarn/client/api/YarnClient.html#signalToContainer(org.apache.hadoop.yarn.api.records.ContainerId,%20org.apache.hadoop.yarn.api.records.SignalContainerCommand)
I'm "extremely" new to Kubernetes, and I wanted to try it out on my local machine, which is running Windows 10 along with HyperV. I saw that minikube is used for local development, and I was able to find in on Chocolatey, so I installed it using that:
choco install minikube -y
(I think this also installs kubectl)
The problem I have is that I'm not able to start it; I'm running the following command:
minikube start --vm-driver=hyperv
I have an external switch configured in HyperV (I found it as a suggestion somewhere), but when I run the command, it's stuck in Creating VM ...
I thought maybe it would give me a clue if I look at the VM created in HyperV, and when I open that, I see the following:
So, it seems that it's waiting for input, and that's why it's stuck! I tried searching for the problem, but to no avail.
I would appreciate any help
PS: It seems to me that if I wait long enough, the following message appears on the console:
Temporary Error: provisioning: error getting ssh client: Error dialing
tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate,
attempted methods [none publickey], no supported methods remain
So, somehow by chance, I think I found how to resolve the issue.
First thing is that: the fact the VM is displaying that prompt (minikube login) seems to be normal, and it does NOT prevent the minikube start from succeeding.
To resolve the issue, this is what I did:
Delete ~/.kube directory
Delete ~/.minikube directory (in case it exists)
The MOST IMPORTANT step: stop/start the Hyper-V Virtual Machine Management Windows service
These steps seem to have solved the issue for me
PS: I used this command to start minikube and enable verbose logging:
minikube start --vm-driver hyperv -v 7 --alsologtostderr
Farzad, what resources have you used for setting up the minikube? Can you please clarify what do you mean by "unable to start". Are the regular kubectl commands working?
For example kubectl get nodes? That is of course if below steps won't help you.
The screenshot you shared shows a running VM:
Minikube runs a single-node Kubernetes cluster inside a VM on your
laptop for users looking to try out Kubernetes or develop with it
day-to-day.
You mentioned that you've created the vSwitch, you should be using a flag that is pointing minikube to use that external vSwitch:
minikube start --vm-driver hyperv --hyperv-virtual-switch "vSwitch name"
You also mentioned choco, did you install kubernetes-cli (as you did not mention it in the question)? It might be the reason why your commands do not work (seems like the new version downloads kubectl with choco install minikube):
kubectl is a command line interface for running commands against
Kubernetes clusters
At this moment I recommend stoping the minikube VM:
minikub stop
Delete the cluster
minikube delete
Sometimes regular minikube stop, minikube delete does not work so you might have to manually turn off the minikubeVM in Hyper-V, then I recommend to go to c:\users\%username%\ and delete .kube and .minikube.
Use cuninst minikube
Restart and install again as specified in the minikube documentation:
choco install minikube
choco install kubernetes-cli
As for the error you mentioned, let's try to run the cluster properly, and if this persists, we will take care of it.
Try this:
kubectl config use-context minikube
I encountered the same issue. The reason was I chose the wrong disk file to start my VM after creating it in Virtual Box.
This solved my issue.
minikube delete
minikube start --vm-driver hyperv -v 7 --alsologtostderr
If I run a docker container with CMD["/use/sbin/ssh", "-D"], I can have them running daemonized, which is good.
Then, I want to run puppet agent too, to build our said container as say an apache server.
Is it possible to do this and then expose the apache server?
Here is another solution. We use ENTRYPOINT docker file instruction as described here: https://docs.docker.com/articles/dockerfile_best-practices/#entrypoint. Using it you can run puppet agent and other services in background before instruction from CMD or command passed via docker run.
I've successfully run a Selenium Grid on my local machine, and I've moved it to a server (windows Server 2008 R2).
The server instance has run successfully with locally launched agents
The server hosted console is visible over the internet
However, when I create a new remote control on a different machine, they build successfully but they do not register with the hub.
The command line is:
ant -Dport=6601 -Dhost=<ip address of my box> -DhubURL=http://ab.cdefg.ca:4444/wd/hub* -Denvironment"firefox" launch-remote-control
I've also used my hostname as a replacement for my ip name (pc78.subdomain.domain.ca)
If I do not specify the Denvironment, I get the following back:
C:\Sgrid\selenium-grid-1.0.8>ant -Dport=6601 -Dhost=pcname.subdomain.domain.ca -Dhu
bURL=http://ab.cdefg.ca:4444/wd/hub* launch-remote-control
Buildfile: C:\Sgrid\selenium-grid-1.0.8\build.xml
launch-remote-control:
[java] Sep 15, 2011 3:37:11 PM com.thoughtworks.selenium.grid.remotecontrol
.RegistrationRequest execute
[java] INFO: Registering to http://ab.cdefg.ca.ca:4444/wd/hub*/registration
-manager/register
[java] Exception in thread "main" java.lang.IllegalStateException: Could no
t register successfuly to http://ab.cdefg.ca.ca:4444/wd/hub*/registration-manage
r/register with environment '*firefox'. Most likely this environment is not defi
ned on the hub.
[java] at com.thoughtworks.selenium.grid.remotecontrol.RegistrationRequ
est.execute(RegistrationRequest.java:29)
[java] at com.thoughtworks.selenium.grid.remotecontrol.SelfRegisteringR
emoteControl.register(SelfRegisteringRemoteControl.java:29)
[java] at com.thoughtworks.selenium.grid.remotecontrol.SelfRegisteringR
emoteControlLauncher.main(SelfRegisteringRemoteControlLauncher.java:27)
BUILD FAILED
C:\Sgrid\selenium-grid-1.0.8\build.xml:90: Java returned: 1
Total time: 1 second
If do specify the Denvironment, I get the following back:
C:\Sgrid\selenium-grid-1.0.8>ant -Dport=6601 -Dhost=pcname.sub.domain.ca -Dhu
bURL=http://ab.cdefg.ca:4444 -Denvironment"firefox" launch-remote-control
Buildfile: C:\Sgrid\selenium-grid-1.0.8\build.xml
BUILD SUCCESSFUL
Total time: 0 seconds
C:\Sgrid\selenium-grid-1.0.8>
However, the console does not recognize or utilize this agent. Nor is this agent visible on http://localhost:4444/console
So I thought, I'll reverse it and use my local as a server and try and register the server as a remote control, but the same problem repeated itself, command line success, but functionally no activity. Sounds like a network problem, so I booted up a third machine, installed and tested selenium grid (works). Console is visible from my laptop, running on my desktop, via ipaddress:4444/console.
I then launched a remote control, had the same problem. Okay, I then turn off the firewall on my local desktop (treating it as my server) and my laptop (treating it as a remote). Same problem.
Finally, thinking maybe the existence of a local console is messing with the remote launch, I reboot and run only the following:
ant -Dport=6601 -Dhost=<laptop ip> -DhubURL=http://<desktop ip>:4444 -Denvironment"firefox" launch-remote-control
Same problem.
Also I can ping the server from my desktop
Is there a setting I'm missing? It seems like everything in each instance is okay, and all of them have the same versions installed. Clearly something isn't getting from one place to the other, but I have no idea how to work around it when everything else seems okay. Many thanks.
You need an "=" after the environment. I.e., -Denvironment="firefox".
ant -Dport=6666 -Dhost=pc78.subdomain.domain.ca -DhubURL=http://ab.cdef.ca:4444 launch-remote-control
Thanks for the kick start - dropping the "/wd/hub*" from the DhubURL and dropping the Denvironment all together actually got me working - thanks for the response. I