Есть проблема долгой остановки сервиса. Например, в случае # ip a|egrep "^[1-9]"|wc -l 133 команда reboot исполняется минут чуть ли не пять. Хотелось бы подумать, что с этим можно сделать. В данном случае, основная масса - это 802.1q интерфейсы. В принципе, я, пока, не представляю вариантов, когда интерфейсосов может быть много, кроме этого случая и случая со всякими ppp. Соответственно, видятся такие варианты: 1. Самый банальный. Для этого надо ответить на вопрос, а надо ли делать network stop при перезагрузке. Если это ничем особенным не грозит, может быть поступить по принципу init.d/halt c его разным наименованием, и, соответственно, поведением для уровней 0 и 6 ? 2. Если проблемы предполагаются, думаю, можно не гасить некоторые типы интерфейсов: они будут положены при отключении основного физического интерфейса, как в случае с vlan. 3. Ускорить сам процесс для каждого интерфейса, хотя я не смотрел пока, возможно ли это, и откуда задержка такая сама по себе. Хотя 1 и 2 останутся актуальны.
Кстати, в случае 1, можно просто убрать K90network из rc6.d и rc0.d
Если вручную выполнить service network stop и посмотреть на прогресс, то какая именно стадия процесса занимает наибольшее время? И выполняется так же медленно service network start?
Весь набор опытов не провёл, но на stop тратится примерно по 5 секунд на каждый 802.1q интерфейс. При загрузке network стартует всего (относительно) секунд за 30. Завтра постораюсь подробнее посмотреть.
В общем, получается, что скорость остановки отдельно взятого интерфейса линейно зависит от их общего количества.
Ага, вот это интересно. Интерфейсы собраны через vlantab или каждый индивидуально?
Каждый индивидуально. vlantab оказался неудобен из-за необходимости индивидуально работы с интерфейсами. Кстати, пока экспериментировал, всплыл такой момент, что restart не трогает существующие интерфейсы, если информация о них удалена. Наверное, rmmod стоит делать при restart, несмотря на NEVER_RMMOD=yes. Это отдельным фичереквестом повесить ?
Архивом /etc/net не пришлёте мне для воспроизводства?
Created attachment 2494 [details] набор 802.1q интерфейсов Да там ничего особенного, главное количество. Я себе, для опытов, вот такой набор насоздавал. С таким количеством у меня 3 секунды на интерфейс получается примерно. Только я далеко не продвинулся: понятно только, что долго исполняются вызовы вида /etc/net/scripts/ifdown eth0.23 skiphot
Воспроизвёл у себя.
Могу пояснить следующее: для каждого интерфейса в конфигурации по умолчанию включена опция IFDOWN_CHILDREN. Это значит, что если какой-то другой интерфейс имеет в REQUIRES или HOST имя текущего останавливаемого интерфейса, то этот другой будет предварительно остановлен. Цепочки зависимостей могут иметь произвольную длину, главное, чтобы они не были циклами (такие случаи контролируются). Для того, чтобы эта схема работала, для каждого интерфейса ищутся зависящие от него, а в условиях наследования опций и множественности профилей для этого приходится выполнить pickup_options для каждого потенциального интерфейса. Таким образом, задача остановки всех имеет квадратичную сложность, а время остановки каждого интерфейса действительно линейно зависит от их количества. Алгоритму можно дать подсказку, которая его ускорит --- поместить в /etc/net/ifaces/default/options-vlan строку "IFDOWN_CHILDREN=0". Это подразумевает, что от VLAN-интерфейсов действительно не зависят другие интерфейсы, например, туннели. Если же зависят, то для тех VLAN-интерфейсов, которые упомянуты в REQUIRES или HOST, необходимо будет выборочно включить IFDOWN_CHILDREN. Попробуйте.
Стало значительно лучше, спасибо. Но вариант не делать network stop при reboot, мне кажется, стоит обдумать. И rmmod при stop/restart.
Ну дак может сделать IFDOWN_CHILDREN=0 по дефолту для vlan-интерфейсов?
(In reply to comment #12) Тут надо подумать/посмотреть, какие последствия это будет иметь, если к vlan привязать тонель. Теоретически должно нормально быть, а как на практике - вопрос. А с точки зрения вероятности ситуаций "много vlan" и "тонель через vlan", последняя, возможно, не менее вероятная...
Проблему объехали, вопрос закрываю.