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
  • 612
  • 2
  • 9
  • 19
  • 2
    Possible duplicate of [Is there a safe way to disable DHCP from command line?](https://askubuntu.com/questions/327412/is-there-a-safe-way-to-disable-dhcp-from-command-line) – Videonauth Nov 15 '17 at 16:07

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
  • 1
    Sorry, but can someone elaborate on exactly how this differs from what is done in the OP here? I've read this three times and I can't seem to tell the difference. – fostandy Aug 16 '14 at 10:37
  • Is it about modifying ('touch') the file so the date changes? Am I supposed to only edit the file AFTER I've brought down the interface? If so, how can I 'undo' the fact that I've edited it before? – fostandy Aug 16 '14 at 10:43
  • 3
    @fostandy ["*ifupdown doesn't support the modifying of interface definitions in /etc/network/interfaces while the related interfaces are up*"](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266175). Here, the interface is stopped **before** the file is modified. – Bruno Nov 15 '14 at 00:14
  • 1
    @Bruno - thanks for clarifying. Out of curiousity what do you do if you've already irrevocably edited the `/etc/network/interfaces` file? Is there a way to force a reset to defaults and and start again? – fostandy Dec 01 '14 at 08:22
  • ... as @fostandy asked, is there a way to correct that behavior once the modification is made? I guess it doesn't happen all the time : just installed 4 servers, 2 out of them still have `dhclient` running... – ionreflex Jun 12 '15 at 18:25
  • 8
    I was baffled as to why it should make a difference but then a clever friend of mine explained it very nicely. The problem is if the file is edited and then `ifdown` is run, network manager does not know that it needs to stop `dhclient`, since all it sees in the `interfaces` file is a static entry. After, the interface is down, issuing `ifup` correctly reads and applies the static settings, but it also doesn't know that `dhclient` had been started. – paracycle Oct 23 '15 at 18:48
  • I did as suggested but I can still see dhclient3 running. Does it hold true for precise (ubuntu 12.04)?? – AjB Jun 01 '16 at 10:20
  • 2
    What I mean is I've to manually `pkill` dhclient and dhclient3 since following the aforementioned steps do NOT kill them automatically – AjB Jun 01 '16 at 10:44
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
  • 19,395
  • 55
  • 76
  • 81
Patrick Deelman
  • 41
  • 1
  • I had the exact same issue, and learned the hard way, that a later file (like 99-eth0.cfg) was indeed NOT overriding previous statements! So, thanks for your input ;) – Daywalker Mar 20 '18 at 18:17
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
  • 3
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
  • 3