18

I modify dhcp to static in /etc/network/interfaces (like below).

# The primary network interface
auto eth0
iface eth0 inet static
netmask 255.255.0.0
address 10.10.130.128
gateway 10.10.1.1

Then restart the interface.

$ sudo ifdown eth0; sudo ifup eth0
...
$ ifconfig
eth0      Link encap:Ethernet 
          inet addr:10.10.130.128  Bcast:10.10.255.255  Mask:255.255.0.0

So the new address kicks in.

But DHCP is still there?

$ ps aux | grep dhc
root    ... dhclient3 -e IF_METRIC=100 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -1 eth0

Is that normal? If not, how to restart interface in static IP while stop DHCP at the same time?

Thanks a lot.

user276851
  • 652
  • 3
  • 10
  • 21

4 Answers4

25
  1. You first have to shutdown the interface (in dhcp mode) sudo ifdown eth0

  2. Then edit the config nano /etc/network/interfaces

    # The primary network interface
auto eth0
iface eth0 inet static
netmask 255.255.0.0
address 10.10.130.128
gateway 10.10.1.1

  3. Bring the interface back up sudo ifup eth0

Otherwise dhclient doesn't correctly shuts down,

pvc
  • 366
  • 3
  • 5
4

I had the same issue (Ubuntu 16.04). However, this was a cloud instance and I could not ifdown the interface that easily.

Short answer: I removed the file /etc/network/interfaces.d/50-cloud-init.cfg ifup was triggered by that specific file.

Long answer: I configured the interface using the /etc/network/interfaces with a static IP address, but I still found in the daemon.log that dhclient was still requesting IP's from the DHCP and dhclient was started through systemd. Specifically, systemd called the networking.service unit, which called ifup, which read both the interfaces file and the 50-cloud-init.cfg file. Resulting in some conflicts, but still a functional network.

Kevin Bowen
  • 20,055
  • 57
  • 82
  • 84
Patrick Deelman
  • 41
  • 1
1

I found for me, this was due to gnome's NetworkManager still running and thinking it was in charge of the device. In hindsight this should have been obvious as ps showed dhclient was being launched by NetworkManager.

Once I restarted my system the device went to "unmanaged" in NetworkManager and it stopped trying to configure it. Perhaps I could have achieved the same thing just by stopping/restarting NetworkManager, I'm not sure.

fostandy
  • 121
0

In my case I was trying to configure a Debian 11 generic cloud image with cloud-init and a static IP on my KVM host (using dmacvicar libvirt Terraform provider)

My network-config file was:

version: 2
ethernets:
  ens3:
    dhcp4: false
    addresses: [10.1.0.100]
    gateway4: 10.1.0.1
    nameservers:
      addresses: [10.1.0.1 1.1.1.1]
      search: [home.lab]

Then I was surprised that during VM creation, the interface was requesting a DHCP lease before cloud-init config would actually kick in and configure the interface as per my static settings (exacltly like the OP described)

After a minute or so, the "mysterious" dhclient gave up waiting for an offer (that was expected as DHCP is disabled on my libvirt network) and is left running in the background. Then the boot sequence continues and cloud-init kicks in, rendering the correct static config in /etc/network/interfaces.d/50-cloud-init.cfg. At that point, the interface gets the expected static IP (ip address show proves that, and you can also ping things by IP), however is leaving DNS resolution broken. I guess it's a side effect of the dhclient fiasco.

Well after some digging it turns out the /etc/network/interfaces file, in addition to sourcing source-directory /etc/network/interfaces.d it also sources the extra directory /run/network/interfaces.d/. To my surprise, that /run directory contains an interface definition for ens3 where it is being configured in dhcp mode!

So now that I knew where the unexpected dhcp request was coming from, it was a matter of disabling it, since it was conflicting with the correct settings in /etc/network/interfaces.d/50-cloud-init.cfg.

Unfortunatelly disabling the intial dhcp request happens before cloud-init kicks in, so really no easy way to prevent dhclient wasting a precious minute or so trying to get an offer that will never come.

What I was able to accomplish though, was fixing DNS resolution by using the following bootcmd: block in my user-data

bootcmd:
  - cloud-init-per once down ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once up ifup ens3

In the above commands, I'm bringing the interface down which stops the dormant dhclient process, then I'm removing the interface definition file that sets ens3 in dhcp mode, and finally I'm bringing the ens3 interface back up, which applies what's set in /etc/network/interfaces.d/50-cloud-init.cfg like a champ.

With that, the subsequent cloud-init stages in the initial boot process were now able to fully reach the internet by name. That was critical for the later stages such the packages: block to succeed, since it needed DNS working to resolve the apt repo server name.

Here's the more detailed user-data excerpt:

bootcmd:
  - cloud-init-per once ifdown ifdown ens3
  - cloud-init-per once bugfix rm /run/network/interfaces.d/ens3
  - cloud-init-per once ifup ifup ens3

packages:


    

  • qemu-guest-agent
    • 

  • locales-all
    • 



package_update: true
package_upgrade: true
package_reboot_if_required: true


runcmd:


    

  • [ systemctl, start, qemu-guest-agent ]
    • 



final_message: "The system is finally up, after $UPTIME seconds"

I thought this might help others which experience OP's issue in a cloud-init setup.

References:

donhector
  • 111