I've followed the instructions at https://github.com/docker/swarm/blob/master/CONTRIBUTING.md to run Swarm's integration tests, but they do not work. The command ./test/integration/run.sh gives unusual error messages. (See http://pastebin.com/hynTXkNb for the full output).
The message about swappiness is the first thing that looks wrong. My kernel does support it - I tested it. /proc/sys/vm/swappiness is readable and writable, and configurable through sysctl.conf .
The next line that looks wrong is the chmod. It tries to access a file in /usr/local/bin - which is wrong because Docker is installed to /usr/bin , and because that file wouldn't be writable by anyone but root anyway.
I know the daemon is running, and working correctly. For example:
user#box:~$ docker run debian /bin/echo 'hello world asdf'
WARNING: Your kernel does not support memory swappiness capabilities, memory swappiness discarded.
hello world asdf
Does anyone know how to fix this issue, and get the integration tests running?
If not, does anyone at least know where to dig into the code in Docker to find out what is failing?
Related
I am a complete noob to Docker, I apologize if this a simple question, I seem to have a significant installation/configuration error in Docker. I am working on a fresh install of Ubuntu 20.04 and Docker version 20.10.12, build e91ed57.
I am literally trying to follow the basic Docker tutorial for beginners from their website and the second command is not working.
The tutorial is no big deal, I can switch tutorials to something more up to date, but it seems that key functionality of Docker is not working correctly.. symlinks.
This command docker build -t getting-started . results in this error:
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/<user>/Downloads/WebDev/Docker/tutorial/getting-started-master/app/Dockerfile: no such file or directory
I double & triple checked everything. I literally tried every solution found here:
Docker: unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx
Docker build gives "unable to prepare context: context must be a directory: /Users/tempUser/git/docker/Dockerfile"
Nothing worked. I could only execute the command using an explicit path. rather than "." which is going to get annoying pretty quickly when developing real projects.
docker build -t getting-started ~/Downloads/WebDev/Docker/tutorial/getting-started-master/
All documentation states docker build -t getting-started . is the correct command, so I am worried about continuing with a "broken" docker installation.
I ran the docker ./check-config.sh script and it shows all is well except CONFIG_RT_GROUP_SCHED: missing which I thought was inconsequential for the moment since hello-world image worked as expected.
Hhhmmm?
What directory are you in when running these commands? From your error it seems you are in the /app directory, whilst you should probably be 1 directory up.
Or, alternatively, your dockerfile is 1 directory below where it was intended to be. I draw this conclusion by comparing the 2 paths you mention:
~/Downloads/WebDev/Docker/tutorial/getting-started-master/app/Dockerfile
vs
~/Downloads/WebDev/Docker/tutorial/getting-started-master/
If the second one works, then the dockerfile is under getting-started-master and not under /app.
Fyi: Docker has a context and unless you explicitly specify it to be something different, by default it's going to be the directory the Dockerfile is located in.
I'm currently trying to port my image optimizer application to a NanoServer docker image. One of the tools my image optimizer uses is truepng.exe. (Can be downloaded here: http://x128.ho.ua/clicks/clicks.php?uri=TruePNG_0625.zip)
I simply created a nanoserver container and mounted a folder that contained truepng.exe:
docker run --rm -it -v C:\data:C:\data mcr.microsoft.com/windows/nanoserver:2004-amd64
When I now run truepng.exe I expect some output regarding command line arguments missing:
C:\MyLocalWindowsMachine>truepng
TruePNG 0.6.2.5 : PNG Optimizer
by x128 (2010-2017)
x128#ua.fm
...
However when I call this from inside the nanoserver docker container I basically see no output:
C:\data>truepng
C:\data>echo %ERRORLEVEL%
-1073741515
As you can see above, the exit code is set to -1073741515. According to this it typically means that there's a dependency missing.
I then downloaded https://github.com/lucasg/Dependencies to see the dependencies of truepng:
It seems it has some dependencies on 5 DLL's. Looking these up I found that there's apparently something called 'Reverse Forwarders': https://cloudblogs.microsoft.com/windowsserver/2015/11/16/moving-to-nano-server-the-new-deployment-option-in-windows-server-2016/
According to the following post though they should already be included in nanoserver: https://social.technet.microsoft.com/Forums/en-US/5b36a6d3-84c9-4940-8b7a-9e2a38468291/reverse-forwarders-package-in-tp5?forum=NanoServer
After all this investigation I've also been playing around with manually copying over the DLL's from my local machine (system32) to the docker machine without any success (it just kept breaking other things like the copy command which required me to recreate the container). Next to that I've also copied the files from SysWOW64, but this didn't help either.
I'm currently quite stranded on how to proceed further as I'm not even sure if the tool is missing dependencies or if something else is going on. Is there a way to investigate what DLL's are missing once a tool is starting?
Kind regards,
Devedse
Edit 1: Idea from #CherryDT
I tried running gflags (https://social.msdn.microsoft.com/Forums/en-US/f004a7e5-9024-4555-9ada-e692fbc3160d/how-to-start-quotloader-snapsquot?forum=vcgeneral) which gave the following output:
C:\data>"C:\data\gflags.exe" /i TruePNG.exe +sls
Current Registry Settings for TruePNG.exe executable are: 00000000
After this I tried running Dbgview.exe, this however never resulted in a log file being written:
C:\data>"C:\data\DebugView\Dbgview.exe" /v /l debugview-log.txt /g /n
C:\data>
I also started TruePNG.exe again, but again, no log file was written.
I tried querying the EventLogs using a dotnet core application, but this resulted in the following exception:
Unhandled exception. System.InvalidOperationException: Cannot open log Application on computer '.'. This function is not supported on this system.
at System.Diagnostics.EventLogInternal.OpenForRead(String currentMachineName)
at System.Diagnostics.EventLogInternal.GetEntryAtNoThrow(Int32 index)
at System.Diagnostics.EventLogEntryCollection.GetEntryAtNoThrow(Int32 index)
at System.Diagnostics.EventLogEntryCollection.EntriesEnumerator.MoveNext()
at EventLogReaderTest.ConsoleApp.Program.Main(String[] args) in C:\data\EventLogReaderTest.ConsoleApp\Program.cs:line 22
Windows Nano Server is tiny and only supports 64-bit applications, tools, and agents. The missing dependency in this case is the entire x86 emulation layer (WoW64), as TruePNG is a 32-bit application.
Windows Server Core contains WoW64 and other components missing from Nano Server. Use a Windows Server Core image instead.
Example command:
docker run --rm -it -v C:\Temp:C:\Temp mcr.microsoft.com/windows/servercore:2004 C:\Temp\TruePNG.exe
Yields the expected output:
TruePNG 0.6.2.5 : PNG Optimizer
by x128 (2010-2017)
x128#ua.fm
TruePNG {options} files
options:
/f# PNG delta filters 0=None, 1=Sub, 2=Up, 3=Average, 4=Paeth, 5=Mixed
/fe PNG extra filters, overrides /f switch
/i# PNG interlace method 0=None, 1=Adam7 (default input)
/g# PNG gamma 0=Remove, 1=Apply & Remove, 2=Keep (default)
[...]
I had Docker Toolbox installed on my Windows 7 PC and I wanted to upgrade my Docker installation to the most recent version. To do that, I decided to delete Docker Toolbox from my system and reinstall it. I uninstalled Docker Toolbox, uninstalled VirtualBox, and removed all instances of both in my files (such as files in AppData). After reinstalling Docker Toolbox and launching the Quickstart Terminal, I ran into the following error:
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this vi
rtual machine, run: C:\Program Files\Docker Toolbox\docker-machine.exe env defau
lt
Looks like something went wrong in step 'Setting env'... Press any key to contin
ue...
So it seems like it failed when "setting env". I'm not sure what that means in this context and I wish there was a way to check some extended logs to get more detail. I tried following the Docker documentation pointing the location of daemon logs in AppData, however, I could not find anything relevant. Something I did find was a file called "no-error-report", though it was empty.
I tried uninstalling everything again and reinstalling with the attribute NDIS5 network type checked, I've ran the Quickstart Terminal as admin, and I still ran into the same exact error.
Any suggestions on how I may approach this issue?
I got this same issue.
I fixed this by doing the below procedures.
I changed the below lines in start.sh
STEP="Setting env"
eval "$("${DOCKER_MACHINE}" env --shell=bash --no-proxy "${VM}" | sed -e "s/export/SETX/g" | sed -e "s/=/ /g")" &> /dev/null #for persistent Environment Variables, available in next sessions
eval "$("${DOCKER_MACHINE}" env --shell=bash --no-proxy "${VM}")" #for transient Environment Variables, available in current session
Changed --no-proxy to --http_proxy since I am using http proxy
I'm trying the NodeMCU Docker build in Ubuntu 16.04.4 LTS for the first time.
I have read the tagged articles here for Docker and NodeMCU, but don't see this particular error.
"docker run hello-world" has no problems.
I have tried the NodeMCU build command in both forms:
$ docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build
and the explicit path variation:
$ docker run --rm -it -v /home/tim/nodemcu-firmware:/opt/nodemcu-firmware marcelstoer/nodemcu-build
In both cases, I get this error:
standard_init_linux.go:187: exec user process caused "exec format error"
I have searched on this error, and most solutions are related to a missing shebang.
However, I'm not sure what script would need the shebang, or why it would be not working in my case but correct for others.
Has anyone else run across this error?
Speaking without deep technical details, this error means that the kernel can not recognize the format of the executable file, thus, it can not run this file. In your case this error is about the executable file which is started when the container is launched. According to the Cmd entry in the output of docker inspect marcelstoer/nodemcu-build, it is a file /bin/sh, which is an ELF executable.
When Linux can not execute ELF binary and returns such an error (about the file format), it usually is related to the system architecture. More specifically, the image marcelstoer/nodemcu-build contains ELF64 executables (i.e. for amd64 architecture), and your system does not support it (is it i386 or even some flavor of arm?). Running docker run hello-world, however, works fine for you, because hello-world image exists for all architectures supported by Docker.
According to the Dockerfile of marcelstoer/nodemcu-build image, it is built from ubuntu, which exists for different architectures, thus, you may try building the marcelstoer/nodemcu-build image on your system rather than pulling it from the dockerhub.
P.S.: regarding the solution you have linked to your question. This is not about your case (ELF binary), rather it is about a script. In case of script, the executable format is recognized by the shebang (#!) at the very beginning of the file, thus, the script must start with #!, not with the newline. That's why the author got the same error: the kernel could not detect that this is a script and failed to start it. Different (but similar) reasons, same error.
My vagrant VM box is super slow when I try to run my Rails app on it, and I'm guessing it's due to the shared folder problem.
I am trying to use rsync to circumvent the problem.
I installed Cygwin and necessary packages, put C:\cygwin64\bin; as PATH environment variable
and then changed my Vagrantfile to
config.vm.synced_folder ".", "/vagrant", type: "rsync"
When I run vagrant up, I Get this error message
$ vagrant up Bringing machine 'default' up with 'virtualbox'
provider... "rsync" could not be found on your PATH. Make sure that
rsync is properly installed on your system and available on the PATH.
What's going wrong here?
Thank you so much ... if there's any other way to run Vagrant VM box smoothly and faster on Windows 7, I would love to hear it too.
This turned out to be a bunch of brick-walls you have to circumvent when installing Rsync and setting it up correctly for Vagrant on Windows 7.
First of all, the error "rsync" could not be found on your PATH. Make sure that rsync is properly installed on your system and available on the PATH. was due to the fact that
1) Environment variable for Cygwin was placed in the latest order in the PATH, I changed it to the beginning of the path
2) During installation of Cygwin and Rsync, I installed individual "subpackages" instead of installing everything, thinking that it would be okay. Turns out I was wrong. I installed everything in the Admin package and Net package (not the SRC but just the bins), and then it started working. I suggest you set-up Cygwin again and really try to download everything if you see that error.
(I found these solutions through this post on SO cygwin + rsync)
Now, I could go into CMD and type rsync, and it would show up correctly. But then when I ran vagrant up it gave me another error saying
There was an error when attempting to rsync a synced folder. Please inspect the error message below for more info.
Host path: /c/Users/xxxxx Guest path: /vagrant
Command: rsync --verbose --archive --delete -z --copy-links
--chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o StrictHostKeyCh
/c/Users/xxxx / vagrant#127.0.0.1:/vagrant
Error: cygwin warning: MS-DOS style path detected:
C:/Users/xxxxxxx Preferred POSIX
equivalent is:
/cygdrive/c/Users/xxxx CYGWIN
environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of
known hosts. rsync: change_dir "/c/Users/xxxxxxx"
failed: No such file or directory (2) rsync error: some files/attrs
were not transferred (see previous errors) (code 23) at
/usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c(1052)
[sender=3.0.9]
I googled solution to this error and found this site. https://github.com/mitchellh/vagrant/issues/3230
Then there's a bug with Vagrant and cwrsync that I mentioned in #3086.
For now, just edit
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.5.1\plugins\synced_folders\rsync\helper.rb
and add hostpath = "/cygdrive" + hostpath to line 74. It's a terrible
solution but quick and simple.
Editing that helper.rb file and adding hostpath at line 74 (just made some blank lines right there and pasted it in) and now it works perfectly!!!!
Rsync makes the shared folder soooooo much faster on Rails!!!! I think it is worth the pain of setting it up correctly. Try it!!
It's not clear from your message, but I think you installed rsync on your machine (the host), while it needs to be installed on the virtual machine you bringing up (the guest).