Static IP assignment leaves stray udhcpc process running in background

[adamleko]

If I vagrant up a boot2docker instance through dvm, everything is fine when the VM starts up:

$ vagrant ssh
…
docker@boot2docker:~$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 08:00:27:E5:4D:D1  
          inet addr:192.168.42.43  Bcast:192.168.42.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fee5:4dd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:632 (632.0 B)  TX bytes:6763 (6.6 KiB)

But there is a udhcpc client being left running on eth1:

docker@boot2docker:~$ ps ax | grep -i eth1
  905 root     /sbin/udhcpc -b -i eth1 -x hostname boot2docker -p /var/run/udhcpc.eth1.pid

For the most part this doesn't seem to hurt but occasionally (randomly?) the IP address on that interface will jump to something in the 192.168.56.x range. Interestingly, this overlaps with a range of addresses provided by Virtualbox:

$ VBoxManage list dhcpservers
NetworkName:    HostInterfaceNetworking-vboxnet0
IP:             192.168.56.100
NetworkMask:    255.255.255.0
lowerIPAddress: 192.168.56.101
upperIPAddress: 192.168.56.254
Enabled:        Yes

The strange thing is that killing and rerunning the udchpc process manually doesn't end up assigning the interface an address but if I kill the VM, change eth1's config to explicitly point to vboxnet0, and start the VM directly in Virtualbox, the machine ends up booting and getting assigned something in that range:

$ ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 08:00:27:D8:52:91  
          inet addr:192.168.56.101  Bcast:192.168.56.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fed8:5291/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1180 (1.1 KiB)  TX bytes:1330 (1.2 KiB)

I'm wondering if the stray udhcpc process in inadvertently causing #8 in some scenarios.

I put together a really dirty fix for this which I would submit as a pull request if I didn't think there was a cleaner way to do:

diff --git a/Vagrantfile b/Vagrantfile
index 28cfee3..7e46c4d 100644
--- a/Vagrantfile
+++ b/Vagrantfile
@@ -52,6 +52,7 @@ module VagrantPlugins
                 ifc = "/sbin/ifconfig eth#{n[:interface]}"
                 broadcast = (IPAddr.new(n[:ip]) | (~ IPAddr.new(n[:netmask]))).to_s
                 comm.sudo("#{ifc} down")
+                comm.sudo("kill $(cat /var/run/udhcpc.eth#{n[:interface]}.pid) || true")
                 comm.sudo("#{ifc} #{n[:ip]} netmask #{n[:netmask]} broadcast #{broadcast}")
                 comm.sudo("#{ifc} up")
               end

Since adding that I haven't seen any more IP address drifts on my local boot2docker VMs. I'm not 100% sure this will fix that issue but it seems a likely cause.

[fnichol]

@adamleko Thank you for finding the underlying issue here! After a lot of searching around, your solution looks to be the best one right now. Again, thanks!!!