Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port collision not fixed when using Docker provider #9067

Closed
tjoelsson opened this issue Oct 18, 2017 · 2 comments
Closed

Port collision not fixed when using Docker provider #9067

tjoelsson opened this issue Oct 18, 2017 · 2 comments
Assignees
Milestone

Comments

@tjoelsson
Copy link

tjoelsson commented Oct 18, 2017

Vagrant version

$ vagrant -v
Vagrant 2.0.0

Host operating system

Mac OSX 10.11.6

Guest operating system

Ubuntu

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  config.ssh.username = "root"
  config.vm.provider "docker" do |docker|
    docker.image = "nineseconds/docker-vagrant"
    docker.has_ssh = true
    docker.remains_running = true
  end
end

Debug output

https://gist.github.com/tjoelsson/fca760f3d0257bb31d76dc8a682db0c8

Expected behavior

Should be able to run two containers simultaneously.

Actual behavior

Port collision stops container from starting.

Steps to reproduce

  1. Prepare two folders (a and b) with identical Vagrantfile
  2. Run vagrant up in folder a
  3. Run vagrant halt in folder a
  4. Run vagrant up in folder b
  5. Run vagrant up in folder a

References

@tjoelsson
Copy link
Author

When using Virtualbox as provider, running vagrant reload would solve the issue. With Docker, it just repeats the same error message.

@briancain briancain added this to the 2.2.9 milestone Apr 10, 2020
@briancain briancain self-assigned this Apr 10, 2020
@chrisroberts chrisroberts modified the milestones: 2.2.9, 2.2.10 May 7, 2020
briancain added a commit to briancain/vagrant that referenced this issue May 8, 2020
… ports

Prior to this commit, if a created but exited container bound a port,
and a new container grabed that same port (say for an ssh port forward),
when the initial container came back up it would fail because the port
also got bound to the second container. This commit fixes that behavior
by first looking at what containers are already bound prior to creating
a container.
briancain added a commit to briancain/vagrant that referenced this issue May 8, 2020
… ports

Prior to this commit, if a created but exited container bound a port,
and a new container grabed that same port (say for an ssh port forward),
when the initial container came back up it would fail because the port
also got bound to the second container. This commit fixes that behavior
by first looking at what containers are already bound prior to creating
a container.
briancain added a commit to briancain/vagrant that referenced this issue May 8, 2020
… ports

Prior to this commit, if a created but exited container bound a port,
and a new container grabed that same port (say for an ssh port forward),
when the initial container came back up it would fail because the port
also got bound to the second container. This commit fixes that behavior
by first looking at what containers are already bound prior to creating
a container.
briancain added a commit to briancain/vagrant that referenced this issue May 8, 2020
… ports

Prior to this commit, if a created but exited container bound a port,
and a new container grabed that same port (say for an ssh port forward),
when the initial container came back up it would fail because the port
also got bound to the second container. This commit fixes that behavior
by first looking at what containers are already bound prior to creating
a container.
briancain added a commit that referenced this issue May 29, 2020
…n-fix

Fixes #9067: Ensure new containers don't grab existing bound ports
@ghost
Copy link

ghost commented Jun 29, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jun 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants