主页 / ubuntu / 问题 / 459140
Accepted
user276851
Asked: 2014-05-02 12:09:55 +0800 CST

为什么我选择静态IP时dhclient还在运行？

  • 772

我在 /etc/network/interfaces 中将 dhcp 修改为静态（如下所示）。

# 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

然后重启界面。

$ 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

所以新地址开始了。

但是 DHCP 还在吗？

$ 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

那是正常的吗？如果没有，如何在停止 DHCP 的同时以静态 IP 重新启动接口？

非常感谢。

networking

4 个回答

  1. Best Answer
    1. 您首先必须关闭接口（在 dhcp 模式下）sudo ifdown eth0

    2. 然后编辑配置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. 恢复界面sudo ifup eth0

    否则dhclient不能正确关闭，

    • 24

  2. 我有同样的问题（Ubuntu 16.04）。但是，这是一个云实例，我不能那么容易地关闭界面。

    简短回答：我删除了文件/etc/network/interfaces.d/50-cloud-init.cfgifup 是由该特定文件触发的。

    长答案：我使用/etc/network/interfaces静态 IP 地址配置接口，但我仍然在 daemon.log 中发现 dhclient 仍在从 DHCP 请求 IP，并且 dhclient 是通过 systemd 启动的。具体来说，systemd 调用了 networking.service 单元，它调用了 ifup，它读取接口文件和 50-cloud-init.cfg 文件。导致一些冲突，但仍然是一个功能网络。

    • 4

  3. 我发现，这是由于 gnome 的 NetworkManager 仍在运行并认为它负责设备。事后看来，这应该是显而易见的，因为ps网络管理器正在启动 dhclient。

    重新启动系统后，设备在 NetworkManager 中进入“非托管”状态，并停止尝试配置它。也许我可以通过停止/重新启动 NetworkManager 来实现同样的事情，我不确定。

    • 1

  4. 在我的例子中，我试图在我的 KVM 主机上配置一个带有 cloud-init 和静态 IP 的 Debian 11 通用云映像（使用 dmacvicar libvirt Terraform 提供程序）

    我的网络配置文件是：

    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]

    然后令我感到惊讶的是，在创建 VM 期间，接口在 cloud-init 配置实际启动并根据我的静态设置配置接口之前请求 DHCP 租约（与描述的 OP 完全一样）

    大约一分钟后，“神秘的”dhclient 放弃等待报价（这是预期的，因为 DHCP 在我的 libvirt 网络上被禁用）并在后台运行。然后引导顺序继续并cloud-init启动，在/etc/network/interfaces.d/50-cloud-init.cfg. 那时，接口获得了预期的静态 IP（ip address show证明了这一点，您也可以通过 IP ping 东西），但是 DNS 解析被破坏了。我想这是 dhclient 惨败的副作用。

    好吧，经过一些挖掘后发现/etc/network/interfaces文件，除了采购source-directory /etc/network/interfaces.d它还采购了额外的目录/run/network/interfaces.d/。令我惊讶的是，该/run目录包含一个接口定义，用于ens3在dhcp模式下配置它！

    所以现在我知道意外的 dhcp 请求来自哪里，这是禁用它的问题，因为它与/etc/network/interfaces.d/50-cloud-init.cfg.

    不幸的是，禁用初始 dhcp 请求发生在 cloud-init 启动之前，因此确实没有简单的方法来防止 dhclient 浪费宝贵的一分钟左右试图获得永远不会到来的报价。

    不过，我能够完成的是通过bootcmd:在我的文件中使用以下块来修复 DNS 解析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

    在上面的命令中，我关闭了接口，停止了休眠的 dhclient 进程，然后我删除了ens3在 dhcp 模式下设置的接口定义文件，最后我ens3重新启动了接口，这应用了在/etc/network/interfaces.d/50-cloud-init.cfg像一个冠军。

    这样，初始启动过程中的后续 cloud-init 阶段现在能够通过名称完全访问互联网。这对于packages:阻止成功的后期阶段至关重要，因为它需要 DNS 工作来解析 apt repo 服务器名称。

    这是更详细的user-data摘录：

    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"

    我认为这可能会帮助其他在 cloud-init 设置中遇到 OP 问题的人。

    参考：

    • 0

相关问题