Thanks, I did: https://github.com/mitchellh/vagrant/issues/5522
Unfortunately I cannot set labels, to tag it appropriately. Am 26.03.2015 um 07:22 schrieb Alvaro Miranda Aguilera: > Seems you got something. > > can you open a new issue?, > > then reference the old one and paste your explanation since make sense > > Alvaro > > > On Wed, Mar 25, 2015 at 11:40 PM, Sascha Vogt <[email protected]> wrote: >> Hi, >> >> I think I found the issue. >> In https://github.com/mitchellh/vagrant/issues/3951 jbarbuto commented >> on 27 Jul 2014 that commenting out >> https://github.com/mitchellh/vagrant/blob/v1.6.3/plugins/communicators/ssh/communicator.rb#L261-L280 >> helped him fix the issue. >> >> Looking at our logs we had the same issue he mentions in that issue. >> Commenting out the connection reuse completely fixed that problem. We >> have in total at least bootet 100 times since then and no locked up >> start (which previously would fail at least 30% of the time). >> >> So from my POV it looks like that on Windows the following can happen: >> - Connection is open >> - connection.exec("") doesn't raise an exception >> - Docker provider does an SSH test (see >> https://github.com/mitchellh/vagrant/blob/v1.7.2/plugins/providers/docker/communicator.rb#L23-L31) >> which obviously fails >> >> -> Endless loop. Connection is never "discarded" but in a state where >> SSH isn't working properly >> >> I guess I'd have to open an issue for that one? >> >> Greetings >> -Sascha- >> >> Am 23.03.2015 um 09:15 schrieb Alvaro Miranda Aguilera: >>> please share a zip file for both Vagrantfiles, happy to have a look. >>> >>> Alvaro >>> >>> >>> On Mon, Mar 23, 2015 at 8:55 PM, Sascha Vogt <[email protected]> wrote: >>>> Hi, >>>> >>>> sorry for the late response, I try to stay away from Windows on the >>>> weekends :) >>>> >>>> Without SSH Vagrant is unable to run provisioners inside the container. >>>> I stripped the provisioners to provide a minimal example where the issue >>>> occurs. >>>> >>>> Any other pointers? >>>> >>>> Greetings >>>> -Sascha- >>>> >>>> Am 20.03.2015 um 23:05 schrieb Alvaro Miranda Aguilera: >>>>> Try this >>>>> >>>>> d.has_ssh=false >>>>> >>>>> once it boots, test vagrant ssh >>>>> >>>>> in my particular case docker boot and i was able to ssh >>>>> >>>>> Alvaro >>>>> >>>>> On Sat, Mar 21, 2015 at 2:30 AM, Sascha Vogt <[email protected]> >>>>> wrote: >>>>>> Hi all, >>>>>> >>>>>> we are using Vagrant on Windows with Docker as provider and a custom >>>>>> Docker host (ubuntu/trusty64) set up with the Docker provisioner. >>>>>> >>>>>> Our Docker containers have SSH enabled. >>>>>> >>>>>> The VM looks like this: >>>>>> config.vm.define "test", primary: true do |test| >>>>>> test.vm.provider "docker" do |d| >>>>>> d.image = "internal-registry:5010/test/sample" >>>>>> d.vagrant_vagrantfile = "../docker-host/Vagrantfile" >>>>>> d.has_ssh=true >>>>>> end >>>>>> end >>>>>> >>>>>> We frequently have issues where Vagrant is stuck in "Waiting for machine >>>>>> to boot", although the container is up (I can log into the Docker >>>>>> container with SSH as well as into the Docker host). Sometimes this >>>>>> happens multiple times in a row and then for hours or even days without >>>>>> it happening once. Also it happens more frequently on some machines than >>>>>> on others, yet I haven't been able to figure out the difference or what >>>>>> causes this. Maybe some minor differences in the involved network >>>>>> hardware? >>>>>> >>>>>> We're on Vagrant 1.7.2 and have VirtualBox versions 4.3.22 and 4.3.26, >>>>>> OS is Win7 Pro 64bit. >>>>>> >>>>>> When the issue occurs, Vagrant with --debug keeps printing >>>>>> DEBUG ssh: Sending SSH keep-alive... >>>>>> to the console until the boot timeout occurs. >>>>>> >>>>>> Does anyone have any idea what this could be? Or how to further debug >>>>>> this? >>>>>> >>>>>> Greetings >>>>>> -Sascha- >>>>>> -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
