При начальной загрузке networking.service является невероятно медленным (5 минут) на Ubuntu 16.10
Согласно systemd-analyze blame, networking-service принимает 5 минут для запуска при начальной загрузке:
Почему это происходит и как я могу зафиксировать его?
4 ответа
Я придумал решение, хотя оно может быть более подходящим чтобы назвать это обходным путем.
Проблема в том, что у network.service тайм-аут по умолчанию равен 5 минутам, и по какой-то причине полный период тайм-аута должен истечь до продолжения загрузки. Итак, загрузка занимает чуть больше 5 минут.
Решение, которое я придумал, заключается в следующем:
sudo systemctl edit networking.service
Добавьте следующую строку:
TimeoutStartSec=10sec
Я до сих пор не знаю первопричину и что именно это время ожидания, но сокращение времени ожидания с 5 минут до 10 секунд делает загрузку довольно быстрой по очевидным причинам.
Вот ссылка на мое решение на форумах Ubuntu: https://ubuntuforums.org/showthread.php?t=2342450&p=13569192#post13569192
Надеюсь, что это поможет.
Отредактируйте / etc / network / interfaces и измените "auto" для интерфейсов на "allow-hotplug"
sudo nano /etc/network/interfaces
Пример: автоматический интерфейс для карты Ethernet auto eth0 измените на allow-hotplug eth0
После этого для меня "systemd-analysis виноват "-> network.service изменяется с 5 минут на 41 с
Из того, что я нашел, возможно, было бы уместно найти лучшую причину. В моем случае это похоже на systemd-networkd.service, который останавливает процесс, и, кроме того, это конкретный сетевой интерфейс, который останавливает networkd.
Поэтому я решил использовать два подхода:
Просто отключите systemd- networkd-wait-online.service после гораздо более удобного для пользователя времени. Этого можно достичь, отредактировав / lib / systemd / system / systemd-networkd-wait-online и добавив параметр в строку ExecStart, которая вызывает службу. Чтобы просто ускорить тайм-аут, добавьте --timeout = 10, чтобы сократить время ожидания до 10 секунд. По умолчанию это 120S. Однако это может быть, ИМХО, не лучший подход, возможно, важно, чтобы какой-то интерфейс действительно был доступен.
ExecStart = / lib / systemd / systemd-networkd-wait-online --timeout = 10Попробуйте игнорировать интерфейс, который, по вашему мнению, может быть основной причиной. В моем случае это был некритический беспроводной канал, который я еще не настроил должным образом. Он был определен в файле netplan yaml, но я еще не настроил wpa_supplicant, чтобы запустить его как AP с IP и т.д. Это была зависимость, которая вызвала срыв. Поэтому я добавил --ignore = int_wlan0 в строку ExecStart. Конечно, критически важные интерфейсы Ethernet появились очень быстро, но networkd ждал чего-то большего от канала WLAN. После того, как игнорирование было выполнено, загрузка сразу перескочила через 2-минутную задержку.
ExecStart = / lib / systemd / systemd-networkd-wait-online --ignore = int_wlan0
Это имеет некоторый смысл, поскольку "man systemd-networkd-wait-online.service" утверждает, что "он будет ждать, пока все ссылки, о которых он знает и которые управляются systemd-networkd.service (8), будут полностью настроены. или не удалось ». Что networkd считает полностью настроенным - вопрос открытый. Судя по моей настройке, это включает в себя наличие IP-адреса, но это может быть просто частным случаем для беспроводных соединений. Я не знаю. Однако с этим исправлением все стало работать намного быстрее, и, по крайней мере, я знаю, что единственной зависимостью была беспроводная связь.
Простое добавление TimeoutStartSec = 10sec у меня не сработало - мне пришлось внести одно небольшое изменение. Посмотрев на /lib/systemd/system/networking.service , я увидел, что атрибут конфигурации был вложен в [Служба]
Я редактировал /etc/systemd/system/networking.service .d / override.conf , чтобы он выглядел следующим образом:
[Service]
TimeoutStartSec=10sec
И теперь он работает