vagrant up/reload just keeps adding new entries to /etc/hosts #12
Comments
|
Are you running vagrant destroy to automatically clean up your hostsfile? Works fine for me on both OS X and cygwin. If you don't destroy your vagrant boxes properly, the auto-cleanup won't happen and you will leave entries in your hostsfile. In that case, just manually delete all the vagrant hostsfile entries and run vagrant up again. |
|
Keep open until resolved and 'vagrant reload' and 'vagrant suspend + vagrant up' works as expected in Vagrant normally |
|
´´´ $ vagrant status default saved (virtualbox) To resume this VM, simply run $ vagrant up
Generating autoload files $ grep dev /etc/hosts The problem is with the Vagrantfile that always adds a new virtual network interface without removing the old one. Running 'vagrant destroy' in between will clean up the hosts file but still leaves the virtualbox network interface behind. Please check how this is solved in other Vagrantfiles so that creating and deleting the virtual network interface is reliable. |
|
@ottok Which OS are you using? |
|
We could change the Vagrantfile to give a static ip address for example in the config.yml so even though /etc/hosts would have multiple entries they would be the same entries. I didn't want to hardcode the IP-address in case people are using multiple boxes at the same time. # Use random ip address for box
# This is needed for updating the /etc/hosts file
config.vm.network :private_network, ip: "192.168.#{rand(255)}.#{rand(255)}"https://github.com/Seravo/wordpress/blob/master/Vagrantfile#L36-L38 |
|
Vagrant 1.7.2 on Ubuntu 12.04.5 LTS |
|
Is it possible to write in the Vagrantfile the host line adding so that it is done only when a new box is bootstrapped and not otherwise? Or that before creating new virtual network interfaces the previous ones (and /etc/hosts entries) would be deleted? Is it possible to trigger the same cleanup code which is run in 'vagrant destroy' to avoid getting doulbe /etc/hosts entries? Or can you force in the Vagrantfile that 'vagrant destroy' is always run before the rest of the Vagrantfile executes? As I understood this is what you are now doing, always running "vagrant destroy && vagrant up" so maybe the easiest (but a bit stupid) solution is to embed "vagrant destroy" inside the "vagrant up" (=Vagranfile stanzas) command |
|
really what it should do, is during any vagrant up/halt/destroy/reload invocation, it should check whether the vagrant boxes in the hostsfile are actually running and remove / add entries accordingly. I guess we need to fix this upstream https://github.com/cogitatio/vagrant-hostsupdater |
|
It's possible but this is a upstream error rather than in our config: agiledivider/vagrant-hostsupdater#67 Can you try following:
|
|
Seems to be done in this fork: weynhamz/vagrant-hostsupdater@69df40a |
|
@ottok @anttiviljami this fork seems to do it. I'm just not sure how to use that and I don't have linux machine where to try this out |
|
Have you ever noticed that upstream is dead, last updated in 2013 and has since 12 open PRs? https://github.com/cogitatio/vagrant-hostsupdater/pulls After browsing the 53 forks at https://github.com/cogitatio/vagrant-hostsupdater/network I found this which looks like it could be the solution weynhamz/vagrant-hostsupdater@69df40a |
|
@ottok working to remedy the upstream issue! I'll keep this issue updated if I hear something. |
|
@ottok I pulled this in and will be testing it shortly. |
|
This has been fixed for a long while already. |
Hello!
Every time I run 'vagrant up' or 'vagrant reload' or similar commands, the IP address of the Vagrant box changes (in fact a new Virtualbox network interface is created every time). My /etc/hosts gets populated with ever new lines. As only the first line matches, it means that in effect my browser never finds the Vagrant server unless I manually keep cleaning up the /etc/hosts file over and over again.
This is extremely annoying an probably impossible to debug to those who don't know where to look.
The text was updated successfully, but these errors were encountered: