У меня есть сервер Debian 10, который, как мне кажется, может / должен загружаться быстрее, но я не знаю, в чем проблема.
я вижу A start job is running for Raise network interfaces при загрузке и глядя на systemd-analyze blame кажется, много времени проводится в networking.service (Я пропустил службы ниже 50 мс).
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 user@0.service
50ms nmbd.service
Делая systemctl stop networking.service и systemctl 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 * на это сделал однако улучшить хотя бы время для начала маршрутизации. Проверка связи с другой сетью с другого устройства после запуска сервера занимает около 1 минуты с auto и ~ 32 секунды с allow-hotplug (возможно, потому, что интерфейсы запускаются параллельно?), и я сразу получаю консоль без A start job is running сообщение. При изменении br0 на него этот интерфейс не запускался автоматически, поэтому я оставил его.
Также только когда auto активен на интерфейсах 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 <Jason@zx2c4.com>. All Rights Reserved.
Отключение любого интерфейса, кажется, дает мне ~ 10 секунд на интерфейс
я имел именно та же проблема, что и вы (я даже сослался на ваш вопрос об ошибке сервера в это сообщение на форумах пользователей Debian)
Моя проблема оказалась еще одним случаем «голодания энтропии при загрузке» (я предполагаю, что wpa-supplicant нуждался в некоторых случайных данных для обмена ключами, и что ядро заблокировалось, ожидая, пока генератор случайных чисел предоставит случайные данные). Оказывается, это на удивление распространенная проблема - к сожалению, почти все «так называемые решения», которые я видел, просто предполагают сокращение времени ожидания. :-(
Для меня исправление заключалось в установке демона hasge (это еще один генератор случайных данных, который запускается рано во время процесса загрузки, поэтому, когда wpa-supplicant запрашивает его, доступно много энтропии), таким образом:
sudo apt install haveged
Наслаждаться!! :-)
Больше информации:
Установка 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 <Jason@zx2c4.com>. 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 не работал до перезапуска вручную. Это было «исправлено» с помощью следующего переопределения для network.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 user@0.service
Вы проверяли, отключена ли systemd-networkd-wait-online.service?
"" "systemd-networkd-wait-online - это системная служба oneshot (см. systemd.service (5)), которая ожидает настройки сети. По умолчанию она будет ждать всех ссылок, о которых она знает и которые управляемый systemd-networkd.service (8), чтобы он был полностью настроен или потерпел неудачу, и по крайней мере одна ссылка для получения оператора связи. "" " https://manpages.debian.org/testing/systemd/systemd-networkd-wait-online.service.8.en.html
Также сначала убедитесь, что в вашей сети нет мошеннических серверов. Может быть, широковещательный DHCP-сервер с недействительной арендой?