Debian - 启动缓慢等待网络

Debian - 启动缓慢等待网络

我有一台 Debian 10 服务器,我认为它可以/应该启动得更快,但我不知道问题是什么。

我看到A start job is running for Raise network interfaces在启动时,看起来systemd-analyze blame似乎花费了很多时间networking.service (我忽略了低于 50ms 的服务)。

         50.846s networking.service
          1.872s smb.mount
           717ms nftables.service
           560ms ifupdown-pre.service
           544ms systemd-logind.service
           205ms systemd-journald.service
           194ms dev-nvme0n1p2.device
            88ms systemd-udev-trigger.service
            83ms smbd.service
            66ms libvirtd.service
            61ms lvm2-monitor.service
            60ms chrony.service
            57ms [email protected]
            50ms nmbd.service

但执行 asystemctl stop networking.servicesystemctl start networking.service只需不到 2 秒。

这是我的 /etc/network/interfaces,供参考(br0 用于虚拟机):

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto enp5s0
iface enp5s0 inet static
        address 192.168.1.190
        netmask 255.255.255.0
        gateway 192.168.1.1 

auto enp9s0
iface enp9s0 inet manual

auto enp8s0
iface enp8s0 inet static
        address 10.36.14.242
        netmask 255.255.255.0
        post-up ip route add 10.0.0.0/8 via 10.36.14.1 dev enp8s0
        pre-down ip route del 10.0.0.0/8 via 10.36.14.1 dev enp8s0

auto br0
iface br0 inet static
        address 10.36.15.11
        netmask 255.255.255.0
        bridge_ports enp9s0
        bridge_stp off
        bridge_fd 0

auto wg-p2p
iface wg-p2p inet static
        address 10.88.88.1
        netmask 255.255.255.0
        pre-up ip link add $IFACE type wireguard
        pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf
        post-down ip link del $IFACE

auto我确实看到一些关于更改为的帖子allow-hotplug,但解释听起来好像它只是启动接口而不阻止启动,即到达网络的时间是相同的。将 enp* 接口更改为做过但是至少可以缩短启动路由的时间。启动服务器后,从另一台设备 ping 另一个网络大约需要 1 分钟,auto而 大约需要 32 秒allow-hotplug(可能是因为接口是并行启动的?),我立即得到了一个控制台,但没有消息A start job is running。但是将 br0 更改为它会导致该接口无法自动启动,所以我保留了它。

仅有的当自动在 enp* 接口上处于活动状态时,我会A stop job is running for Raise network interfaces关机,这大约需要 50 秒才能完成。

所以我想知道是否可以保留这些接口allow-hotplug(也许某些服务可能存在接口绑定问题?),以及是否有任何其他问题我可以修复以改善启动时间。

编辑:

相关输出为dmesg -T

[Mo Jun 24 13:16:48 2019] IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready
[Mo Jun 24 13:16:51 2019] igb 0000:05:00.0 enp5s0: igb: enp5s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[Mo Jun 24 13:16:51 2019] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready
[Mo Jun 24 13:16:58 2019] r8169 0000:09:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw
[Mo Jun 24 13:16:58 2019] RTL8211E Gigabit Ethernet r8169-900:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-900:00, irq=IGNORE)
[Mo Jun 24 13:16:58 2019] r8169 0000:09:00.0 enp9s0: No native access to PCI extended config space, falling back to CSI
[Mo Jun 24 13:16:58 2019] IPv6: ADDRCONF(NETDEV_UP): enp9s0: link is not ready
[Mo Jun 24 13:17:01 2019] r8169 0000:09:00.0 enp9s0: Link is Up - 1Gbps/Full - flow control off
[Mo Jun 24 13:17:01 2019] IPv6: ADDRCONF(NETDEV_CHANGE): enp9s0: link becomes ready
[Mo Jun 24 13:17:08 2019] RTL8211E Gigabit Ethernet r8169-800:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-800:00, irq=IGNORE)
[Mo Jun 24 13:17:08 2019] IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
[Mo Jun 24 13:17:11 2019] r8169 0000:08:00.0 enp8s0: Link is Up - 1Gbps/Full - flow control off
[Mo Jun 24 13:17:11 2019] IPv6: ADDRCONF(NETDEV_CHANGE): enp8s0: link becomes ready
[Mo Jun 24 13:17:18 2019] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[Mo Jun 24 13:17:18 2019] br0: port 1(enp9s0) entered blocking state
[Mo Jun 24 13:17:18 2019] br0: port 1(enp9s0) entered disabled state
[Mo Jun 24 13:17:18 2019] device enp9s0 entered promiscuous mode
[Mo Jun 24 13:17:18 2019] br0: port 1(enp9s0) entered blocking state
[Mo Jun 24 13:17:18 2019] br0: port 1(enp9s0) entered forwarding state
[Mo Jun 24 13:17:18 2019] IPv6: ADDRCONF(NETDEV_UP): br0: link is not ready
[Mo Jun 24 13:17:19 2019] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[Mo Jun 24 13:17:28 2019] wireguard: loading out-of-tree module taints kernel.
[Mo Jun 24 13:17:28 2019] wireguard: module verification failed: signature and/or required key missing - tainting kernel
[Mo Jun 24 13:17:28 2019] wireguard: WireGuard 0.0.20190406 loaded. See www.wireguard.com for information.
[Mo Jun 24 13:17:28 2019] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <[email protected]>. All Rights Reserved.

禁用任何接口似乎为每个接口节省了约 10 秒的时间

答案1

我有确切地和你一样的问题(我甚至在此帖子发布到 Debian 用户论坛

我的问题原来是“启动时熵饥饿”的另一个实例(我猜想 wpa-supplicant 需要一些随机数据来进行密钥交换,而内核在等待随机数生成器提供随机数据时被阻塞)。事实证明这是一个令人惊讶的常见问题 - 不幸的是,我见过的几乎所有“所谓的解决方案”都只是建议减少超时时间。 :-(

对我来说,解决方法是安装 havege 守护进程(这是另一个在启动过程中尽早启动的随机数据生成器,因此当 wpa-supplicant 请求时,有足够的熵可用),因此:

sudo apt install haveged

享受!! :-)

更多信息:

答案2

您是否检查过 systemd-networkd-wait-online.service 是否被禁用?

"""systemd-networkd-wait-online 是一个一次性的系统服务(参见 systemd.service(5)),用于等待网络配置。默认情况下,它将等待它所知道的、由 systemd-networkd.service(8) 管理的所有链接完全配置或失败,并且至少等待一个链接获得运营商。""" https://manpages.debian.org/testing/systemd/systemd-networkd-wait-online.service.8.en.html

另外,首先要确保您的网络没有恶意服务器。可能是具有无效租约的广播 DHCP 服务器?

答案3

安装 ifupdown2 将网络时间缩短至约 6 秒。

          5.974s networking.service
          1.904s smb.mount
           773ms nftables.service
           552ms systemd-logind.service
           208ms systemd-journald.service
           205ms dev-nvme0n1p2.device
            96ms systemd-udev-trigger.service
            90ms lvm2-monitor.service
            79ms smbd.service
            62ms chrony.service
            53ms nmbd.service
            50ms libvirtd.service
[Di Jun 25 05:21:06 2019] [drm] Initialized amdgpu 3.27.0 20150101 for 0000:42:00.0 on minor 0
[Di Jun 25 05:21:09 2019] igb 0000:05:00.0 enp5s0: igb: enp5s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[Di Jun 25 05:21:09 2019] IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready
[Di Jun 25 05:21:11 2019] r8169 0000:08:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw
[Di Jun 25 05:21:11 2019] RTL8211E Gigabit Ethernet r8169-800:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-800:00, irq=IGNORE)
[Di Jun 25 05:21:11 2019] r8169 0000:08:00.0 enp8s0: No native access to PCI extended config space, falling back to CSI
[Di Jun 25 05:21:11 2019] IPv6: ADDRCONF(NETDEV_UP): enp8s0: link is not ready
[Di Jun 25 05:21:11 2019] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[Di Jun 25 05:21:11 2019] br0: port 1(enp9s0) entered blocking state
[Di Jun 25 05:21:11 2019] br0: port 1(enp9s0) entered disabled state
[Di Jun 25 05:21:11 2019] device enp9s0 entered promiscuous mode
[Di Jun 25 05:21:11 2019] RTL8211E Gigabit Ethernet r8169-900:00: attached PHY driver [RTL8211E Gigabit Ethernet] (mii_bus:phy_addr=r8169-900:00, irq=IGNORE)
[Di Jun 25 05:21:11 2019] br0: port 1(enp9s0) entered blocking state
[Di Jun 25 05:21:11 2019] br0: port 1(enp9s0) entered forwarding state
[Di Jun 25 05:21:11 2019] wireguard: loading out-of-tree module taints kernel.
[Di Jun 25 05:21:11 2019] wireguard: module verification failed: signature and/or required key missing - tainting kernel
[Di Jun 25 05:21:11 2019] wireguard: WireGuard 0.0.20190406 loaded. See www.wireguard.com for information.
[Di Jun 25 05:21:11 2019] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <[email protected]>. All Rights Reserved.
[Di Jun 25 05:21:12 2019] br0: port 1(enp9s0) entered disabled state
[Di Jun 25 05:21:14 2019] r8169 0000:08:00.0 enp8s0: Link is Up - 1Gbps/Full - flow control off
[Di Jun 25 05:21:14 2019] IPv6: ADDRCONF(NETDEV_CHANGE): enp8s0: link becomes ready
[Di Jun 25 05:21:14 2019] r8169 0000:09:00.0 enp9s0: Link is Up - 1Gbps/Full - flow control off
[Di Jun 25 05:21:14 2019] br0: port 1(enp9s0) entered blocking state
[Di Jun 25 05:21:14 2019] br0: port 1(enp9s0) entered forwarding state

也许正常的 ifupdown 会出现一些奇怪的超时问题?这肯定看起来像是一个错误。

编辑:

好吧,看来这并没有解决任何问题,因为接口实际上并没有完全“启动”。我注意到这一点是因为 dnsmasq 直到手动重启才工作。这是通过使用以下 networking.service 覆盖来“修复”的:

[Unit]
Before=network.target shutdown.target network-online.target

但遗憾的是,这又让我回到原点:

         51.036s networking.service
          1.114s smb.mount
           837ms nftables.service
           557ms systemd-logind.service
           211ms systemd-journald.service
           199ms dev-nvme0n1p2.device
           100ms lvm2-monitor.service
            91ms systemd-udev-trigger.service
            77ms smbd.service
            62ms nmbd.service
            58ms chrony.service
            56ms libvirtd.service
            55ms [email protected]

相关内容