I'm running docker on Windows.
When I run a command like docker ps -a or even just docker --version there is a 10 second pause before it produces any output. This seems to happen only when the machine has been idle for a while (for maybe 20 seconds or more?) Then subsequent executions of docker --version will be quick and responsive. If I let the machine sit for a bit, then it goes back to exhibiting the long pause before output again. If I run another docker command immediately after, then it responds quickly again.
I looked through my path to make sure there was nothing weird. I checked power/performance settings. I don't really know where else to look. It's only docker that is behaving like this. Other apps on the machine work fine. So I don't think it has anything to do with the disk or memory or anything like that. I have 32 GB of RAM and <10 GB of it is in use.
This seems a bit mysterious, I know, I'm sorry. Any suggestions of things that I could try to get more information and ultimately figure this out?
It's annoying that half the time when I execute a docker command I have to needlessly wait 10 seconds before the command will start.
Docker version 18.06.0-ce, build 0ffa825
Windows 10 Enterprise
Related
So I am trying to get started developing on Fuchsia and I wanted to get the hello world component to run. However, following these steps doesn't work for me. I'm using core.qemu-x64 running on an Ubuntu 20.04 VM with Virtual Box. I have gotten the emulator to run with fx qemu -N but fx vdl start -N hasn't worked for me.
I run fx serve-updates but it just outputs "Discovery..." and never changes. Then I try to run fx shell run fuchsia-pkg://fuchsia.com/hello-world-cpp#meta/hello-world-cpp.cmx but it says "No devices found." It seem like this shouldn't be an issue because with Linux the device finder should automatically pick it up. Regardless I tried following the MAC instructions and setting the device with fx set-device 127.0.0.1:22. That just makes the run command say "ssh: connect to host 127.0.0.1 port 22: Connection refused". I also tried to set it to the device to the nodename outputted by the fx qemu -N command which is "fuchsia-####-####-####" but that just makes the run command say no devices are found again.
I have verified that I actually have the hello-world packages with the fx list-packages hello-world which outputs all the hello-world packages as expected.
Is there any way I can get the device to be discoverable by the shell command? Alternatively, can I run components like the hello-world component from the qemu emulator directly?
Please let me know if I can provide any additional information.
I guess I just wasn't patient enough. I assumed the emulator was done getting setup because it stopped giving console output and it allowed me to input commands but it seems I just had to wait longer. After 50 minutes of the fx qemu -N command running, the terminal that had fx serve-updates going finally picked up the device. Then I was able to execute the hello world component. It would be nice if the documentation at least gave an idea of how long the different commands would take before they'd be usable.
Very often when running ansible-playbook on the Vagrant VM from Windows, I need to stop in the middle of something by pressing Ctrl+C. This happens if ansible becomes unresponsive or there is some bug we need to fix asap, so there is no point of waiting until provisioner completes.
The probem is that Ctrl+C does not work, some 2 ruby.exe processes get stuck in process tree. Any subsequent vagrant commands fail until you manually kill these ruby processes.
I also use to kill all stucked python ansible processes on the VM before running new provision.
Any way to handle it more jently?
I found this problem as well on Windows and using Puppet Apply. The only way I can happily kill it by opening another terminal/cmd and then vagrant ssh -- sudo pkill puppet. That gracefully terminates the process, and allows me to regain control of my first terminal again.
In short the solution is:
Take a terminal that works.
I find one working gitbash v2.32.0.windows..
The latest available gitbash currently is v2.38.1. But only the old one is working correctly with Vagrant(Oracle VM). The strange thing is that the latest one (gitbash v2.38.1) is working fine with SSH connections to AWS EC2 instances.
Alternatively. Windows PowerShell is working fine with Vagrant(Oracle VM).
If someone needs my bad experience, here it is.
The following terminals DON'T WORK
gitbash v2.38.1 (latest for now)
gitbash V2.36.0
ConEmu v220807 Alhpa (latest for now)
cmder v1.3.20.1282 (latest for now)
I propose using vagrant halt.
Recently while at work we were given an older version of ubuntu (12.04) to work with on a vagrant machine.
I wanted to migrate over to fish or zsh due to them being way better then default bash but I'm encountering a weird error where if I navigate to the /vagrant folder (shared onto the local machine as well) every command I run stalls for 5-10 seconds. Outside of the folder it does fine and has no stalling problems.
Has anyone encountered this before or have any ideas on why this could be happening?
Probably some stat or something taking too long to finish. I will suggest to run strace on bash (if you have patient for that :) ).
Such stat can be for example called from your PROMPT, it's common to have there CWD.
I will suggest to not run commands from there if not necessary. You can call commands outside and provide path to there.
Ofcourse you can play with sharing, there is probably some weak point.
So I have docker set up on OS X by using boot2docker. I have everything working, however, when I run docker run -i -t base /bin/bash it works, the prompt shows up... but it is EXTREMELY slow. By slow, I mean that if I would type one character, it takes about 30 seconds to a minute for that character to show up on the screen. I checked my Activity Monitor to make sure my system wasn't low on memory but that was not the case. It was showing around 85% of idle memory while this process was running. I was curious to see if anyone else on OS X was experiencing issues like this. Any input would be appreciated.
I've experienced the very same problem and as Julian already stated, it's a known issue. But, there is one post in that issue-thread that worked for me (well, at least an adapted version of it).
./boot2docker stop # stop a currently running deamon-instance
./boot2docker delete # remove the vm
rm -rf boot2docker.iso # in my case I had a (very old) iso-image
At this stage any new attempt to re-initialize the boot2docker-vm failed for me. So I was forced to re-install boot2docker itself (and as it turned out I had a very old version). You can do this via Homebrew or with the new installer (whereas, the solution demonstrated in the docker-docu doesn't work anymore). In any case, don't forget to set the DOCKER_HOST variable correct as explained in the documentation:
export DOCKER_HOST=tcp://127.0.0.1:4243
After re-installing boot2docker the following commands should work again:
./boot2docker init # fetches a brand new vm image and initializes
./boot2docker up # now we're back in business
That did it for me - now the performance is as expected
docker run -i -t --rm dockerfile/ubuntu /bin/bash
gives me an (almost) instant bash-prompt.
I have installed msysgit, and I am attempting to use it inside of Hudson. Whenever I run a command in an interactive shell, whether it be git-bash or a command prompt, the commands are instant. When I run them in Hudson, they lag for a very long time.
Running /bin/git help took 63 seconds when I just invoked it. I've never waited long enough to see a clone begin outputting (>10 minutes).
The Hudson mailing list is down, so I figured I would try here...
I've run into this problem as well, and figured out a workaround. When Hudson runs as a service, something is missing that your normal desktop environment has, which causes something to do with the network to have to re-load for each process. msys-1.0.dll attempts to load something in netapi32.dll which causes it to take so long. So I just downloaded plink.exe from PuTTY, and set my GIT_SSH env to use that instead. Problem averted.
Have you tried using the Git plugin for Hudson?