Установка udevd-final не помогает:
https://bugzilla.altlinux.org/show_bug.cgi?id=29282#c34

В режиме NetworkManagerNative всё работает. Поэтому пользователи на Рабочей станции ничего не замечают. Но вот на Сервере у нас NM не устанавливается. Хотя никто не мешает его водрузить, как это делают редхатовцы и федоровцы.

Текущее решение, которое предлагается мной - добавить поддержку systemd-networkd в alterator-net-eth.

На самом деле, об этой проблеме я уже сообщал (год назад):
https://bugzilla.altlinux.org/38774

*** Bug 38774 has been marked as a duplicate of this bug. ***

Помогает ли рекомендация из статьи про Etcnet:

Интеграция с systemd, или что делать если не поднимается интерфейс при старте.

Начиная с версии 0.9.12 в etcnet добавлен Unit для включения интерфейсов по мере их появления в системе. Это позволяет избежать "гонок", когда сетевая подсистема поднимается раньше, чем ОС загружает драйвера для сетевых устройств. Для этого нужно выставить ONBOOT=no в файле options интерфейса и включить его подъём через systemd при загрузке: systemctl enable network@<имя интерфейса>.

Я раньше рекомендовал при подобных гонках добавлять MODULE=... в options-файл интерфейса, что заставляло etcnet перед запуском сделать для него modprobe. Но у этого подхода есть обратная сторона медали: при перезапуске сети модуль выгружается, а если модуль один на несколько интерфейсов, может быть не очень хорошо. Новый вариант с юнитом systemd, возможно, пора сделать дефолтным для дистрибутивов на основе systemd.

(Ответ для Leonid Krivoshein на комментарий #3)
> Новый вариант с юнитом systemd,
> возможно, пора сделать дефолтным для дистрибутивов на основе systemd.

Пожалуйста, не надо этот вариант делать по-умолчанию. Я бы даже не стал рекомендовать :)

С юнитом надо рекомендовать переход на systemd-networkd.

PS: конечно, etcnet все равно надо починить.

(In reply to Alexey Shabalin from comment #4)
> Пожалуйста, не надо этот вариант делать по-умолчанию. Я бы даже не стал
> рекомендовать :)
Речь о том, что при установке выбран etcnet, есть "гонки" и есть рабочий workaround. Это и есть суть ремонта etcnet, должно "из коробки" работать.

> С юнитом надо рекомендовать переход на systemd-networkd.
Тоже вариант, но его ещё надо реализовывать, и если пользователь выбирает не этот вариант, проблема всё равно должна решаться.

(Ответ для Leonid Krivoshein на комментарий #5)
> (In reply to Alexey Shabalin from comment #4)
> > Пожалуйста, не надо этот вариант делать по-умолчанию. Я бы даже не стал
> > рекомендовать :)
> Речь о том, что при установке выбран etcnet, есть "гонки" и есть рабочий
> workaround. Это и есть суть ремонта etcnet, должно "из коробки" работать.

Вот я и говорю, не надо workaround (костыль) делать по-умолчанию. Надо чинить, а не мусор под коврик заметать. Этот workaround совсем не суть ремонта.

(Ответ для Alexey Shabalin на комментарий #6)
> (Ответ для Leonid Krivoshein на комментарий #5)
> > (In reply to Alexey Shabalin from comment #4)
> > > Пожалуйста, не надо этот вариант делать по-умолчанию. Я бы даже не стал
> > > рекомендовать :)
> > Речь о том, что при установке выбран etcnet, есть "гонки" и есть рабочий
> > workaround. Это и есть суть ремонта etcnet, должно "из коробки" работать.
> 
> Вот я и говорю, не надо workaround (костыль) делать по-умолчанию. Надо
> чинить, а не мусор под коврик заметать. Этот workaround совсем не суть
> ремонта.


Ла, конечно.
Но нам нужно дать рекомендации и тем пользователям, которые не дождутся окончания правильного ремонта.

(In reply to Alexey Shabalin from comment #6)
> Вот я и говорю, не надо workaround (костыль) делать по-умолчанию. Надо
> чинить, а не мусор под коврик заметать. Этот workaround совсем не суть
> ремонта.
Написанное можно воспринимать по-разному. :-) Etcnet как служба многим нравится, но архитектурно она не часть systemd и изначально не рассчитывалась на работу в его окружении. Указанный юнит и есть суть ремонта, т.к. единственный способ интегрировать конкретный интерфейс с systemd при желании не гоняться с моментом запуска etcnet. А суть ремонта в твоём понимании -- выкорчёвывать etcnet из дистрибутива и переходить полностью на systemd-networkd? И только это предлагать по умолчанию? Или какой вариант ремонта etcnet тут ещё возможен?

Замечу только, что "предлагать по умолчанию" не значит не предлагать альтернативы.
1. Так как проблема серьезная, то мне кажется, что стоит скорее вынести ее в отдельную статью вики с описанием, что можно сделать сейчас, и сослаться на эту статью в описании продуктов.
2. Я бы подождал sem@ для обсуждения окончательного решения по исправлению баги, он будет в понедельник.

(Ответ для Evgeny Sinelnikov на комментарий #1)
> Установка udevd-final не помогает:
> https://bugzilla.altlinux.org/show_bug.cgi?id=29282#c34

Значит так, тут всё несколько сложнее и интереснее. udevd-final - это имя, которое предоставляет пакет udev-rule-generator. Он проблему не решает. А вот, если установлен пакет udev-rule-generator-net, то проблема решается. Где-то год назад я об этом уже писал:
https://bugzilla.altlinux.org/show_bug.cgi?id=38774#c2

Решается проблема не полностью. При первом запуске системы правил ещё нет, после первого запуска правила появляются и... интерфейс переименовывается из enp0s3, например, в eth0. Ну, а после второй перезагрузки eth0 уже как-то получает по dhcp свой ip, если настроен /etc/net/ifaces/eth0, конечно.

И, в целом, для админа localhost это даже рабочий вариант:
- установил систему;
- загрузил с одним именем интерфейса и без сети;
- перезагрузил с другим именем интерфейса, но уже с сетью.

Проблем тут аж три:
- неудобно и не всегда подходит для облачных решений;
- неудобно при смене сетевой карты, но это у всех так;
- как быть с настройками, которые вносятся при первой загрузке по недоумению в ещё не переименованный интерфейс?

Для развёртывания новых систем с новыми mac-адресами это вызывает неудобство, которое можно превратить даже преимущество. Достаточно при вписывании нового mac-адреса в таблицу имён интерфейсов, вызывать переименование интерфейса вручную при первой загрузке. Это нужно дорабатывать udev-rule-generator-net.

_________________________

Вариант от klark@:
- выставить ONBOOT=no в файле options интерфейса
- включить его подъём через systemd при загрузке: systemctl enable network@<имя интерфейса>.
в целом, работает.

________________________

Итого, если оставаться в рамках etcnet:
- udev-rule-generator-net отсутствует в релизе 9.2 как на Сервере (на 9.1 тоже, кстати), так и на Рабочей станции;
- для Рабочей станции проблему нивелирует режим NetworkManagerNative;
- на Сервере, достаточно прописать вариант от klark@:
# systemctl enable network@<имя интерфейса>.
 Или выполнить сценарий на udev-rule-generator-net:
# настроить сеть вручную (достаточно запустить dhcpcd <имя интерфейса>);
# установить пакет udev-rule-generator-net;
# перезагрузить два раза систему.

Думаю первый вариант проще и предпочтительнее.

Если использовать systemd-networkd на Сервере нужно выполнить другой сценарий:
# настроить сеть вручную (достаточно запустить dhcpcd <имя интерфейса>);
# установить пакет systemd-networkd;
# создать файл /etc/systemd/network/<любое_имя_для_настройки>.network вида:
[Match]
Name=<имя интерфейса>

[Network]
DHCP=yes
UseDNS=yes

Остальное по вкусу:
https://www.freedesktop.org/software/systemd/man/systemd.network.html

_________________________

Но это пока не системные решения, а обходные рабочие сценарии.

Системное решение нужно, конечно, строить немного иначе:
- включать режим от klark@ в alterator-net-eth (прост, ничего не нужно устанавливать, но есть недостатки, см. ниже);
- добавлять поддержку подсистемы systemd-networkd в alterator.

Проработал для этого генерацию systemd-networkd правил в alterator-net-eth. Готовлю обновление.

У второго варианта (systemd-networkd) есть одна два важных преимущества (аналогичных NetworkManager. Кстати, я намеренно отказывался от сценария - использовать его на Сервере - хотя так тоже делают):

- отсутствие диких тормозов на старте системы при использовании dhcp, если dhcp пока не доступен или кабель отключен (тут может быть вопрос: "А кто использует dhcp на сервер?", отвечу: "Используют, и для оборудования используют... ну, и, конечно, в облаках очень даже используют.");

- получение настроек по dhcp при подключении кабеля (это отчасти решается костылём в виде ifplugd, но он не спасает, если кабель не дёргали, а dhcp отсутствовал на стадии загрузки).

Не важно переименован интерфейс ядром или нет. Даже наоборот, если интерфейс переименуется через udev-rule-generator-net и прописан в правилах etcnet, то проблема не возникает.

Для статических адресов, настроенных через etcnet, данная проблема также актуальна.

Простое решение:
# systemctl enable network@<имя интерфейса>

работает без дополнительного прописывания ONBOOT=no как для BOOTPROTO=static, так и для BOOTPROTO=dhcp.


Потенциальные издержки решения:
- задержки при старте системы в случае переименования интерфейса;
- кроме того, если забыть имя старого интерфейса, то потом можно долго искать источник проблемы в виде включенного ожидания события от несуществующего уже интерфейса.

Например:
# systemctl enable network@enp0s3
Created symlink /etc/systemd/system/multi-user.target.wants/network@enp0s3.service → /lib/systemd/system/network@.service.

Символическая ссылка network@enp0s3.service - это то, что может вызвать задержки, если интерфейс enp0s3 будет переименован.

В таске #284439 сервис network будет ждать появления интерфейса перед запуском ifup, по умолчанию 2 секунды. Просьба проверить, у меня работает.

(Ответ для Mikhail Efremov на комментарий #13)
> В таске #284439 сервис network будет ждать появления интерфейса перед
> запуском ifup, по умолчанию 2 секунды. Просьба проверить, у меня работает.

Это ошибочное изменение, на самом деле надо инициализировать через сервис systemd для etcnet - и об этом сказано в документации на wiki.

systemctl enable enp0s3@network

(Ответ для Anton Farygin на комментарий #14)
> (Ответ для Mikhail Efremov на комментарий #13)
> > В таске #284439 сервис network будет ждать появления интерфейса перед
> > запуском ifup, по умолчанию 2 секунды. Просьба проверить, у меня работает.
> 
> Это ошибочное изменение, на самом деле надо инициализировать через сервис
> systemd для etcnet - и об этом сказано в документации на wiki.
> 
> systemctl enable enp0s3@network

В чем же ошибка? 

Документацию на вики можно дополнить.

Ошибка в том, что появился параметр таймаута, который в реальной жизни не нужен - мы никогда не сможем предугадать его значение так, что бы оно устраивало всех пользователей.

Надо переходить на инициализацию интерфейсов по общепринятой схеме, на основании события в udev. И для этого уже все механизмы есть.

Возможно, стоит сделать универсальный сервис, реагирующий на появлению любого интерфейса в системе и запускающий ifup из etcnet для него при наличии конфига. Но последствия такого сервиса надо хорошенько обдумать, возможно он будет не всегда полезен. Хотя NetworkManager, на самом деле, является аналогом именно такого сервиса.

(Ответ для Anton Farygin на комментарий #16)
> Ошибка в том, что появился параметр таймаута, который в реальной жизни не
> нужен - мы никогда не сможем предугадать его значение так, что бы оно
> устраивало всех пользователей.

Именно.

> Надо переходить на инициализацию интерфейсов по общепринятой схеме, на
> основании события в udev. И для этого уже все механизмы есть.

Согласен.

> Возможно, стоит сделать универсальный сервис, реагирующий на появлению
> любого интерфейса в системе и запускающий ifup из etcnet для него при
> наличии конфига. Но последствия такого сервиса надо хорошенько обдумать,
> возможно он будет не всегда полезен. Хотя NetworkManager, на самом деле,
> является аналогом именно такого сервиса.

Да, как раз такой сервис мы уже с Алексеем и запланировали в общих чертах.
Это похоже на systemd-networkd на shell'е или для shell'а, но именно такую
архитекуру мы и задумали для старта и поддержки etcnet.

(Ответ для Anton Farygin на комментарий #14)
> systemctl enable enp0s3@network

Основная проблема тут с обновлением. Я так понимаю, проблема с большой вероятностью стала появляется с новым и ядрами/udev, поэтому пользователи после обновления могут получить систему, в которой сеть не поднимается после загрузки.
Кроме того, проблема скорее всего существует и на системах без systemd (даже с последовательным запуском сервисов интерфейс может не успеть переименоваться до запуска network), там вариант с network@.service не годится.

(Ответ для Mikhail Efremov на комментарий #18)
> (Ответ для Anton Farygin на комментарий #14)
> > systemctl enable enp0s3@network
> 
> Основная проблема тут с обновлением. Я так понимаю, проблема с большой
> вероятностью стала появляется с новым и ядрами/udev, поэтому пользователи
> после обновления могут получить систему, в которой сеть не поднимается после
> загрузки.
> Кроме того, проблема скорее всего существует и на системах без systemd (даже
> с последовательным запуском сервисов интерфейс может не успеть
> переименоваться до запуска network), там вариант с network@.service не
> годится.

Миша, этой проблеме уже сто лет в обед. Я первый раз с ней столкнулся лет пять назад.

Что касается систем без systemd, то как владелец такой, могу сказать что и на ней можно придумать каким образом поднимать интерфейс после его появления - там же udev есть, а значит можно писать правила, отрабатывающие по мере появления интерфейса.

Т.е. - в данном случае systemd отрабатывает в качестве удобного инструмента для запуска скрипта, но в старой жизни этот же функционал можно сделать и другими способами.

> Это ошибочное изменение, на самом деле надо инициализировать через сервис
> systemd для etcnet - и об этом сказано в документации на wiki.
> 
> systemctl enable enp0s3@network

Это изменение не противоречит документации на wiki и не мешает пользоваться решением через systemctl enable enp0s3@network и другими возможными. Однако, оно позволяет обеспечить работоспособность сети после обновления без дополнительных телодвижений.

Кроме того, ждать появления того, что явно прописано в конфиге -- нормальная практика. Не будем забывать, что тот же event driven systemd ждёт появления диска, прописанного в fstab 2 минуты. 2 минуты, а не 2 секунды!

(Ответ для Anton V. Boyarshinov на комментарий #20)
> > Это ошибочное изменение, на самом деле надо инициализировать через сервис
> > systemd для etcnet - и об этом сказано в документации на wiki.
> > 
> > systemctl enable enp0s3@network
> 
> Это изменение не противоречит документации на wiki и не мешает пользоваться
> решением через systemctl enable enp0s3@network и другими возможными. Однако,
> оно позволяет обеспечить работоспособность сети после обновления без
> дополнительных телодвижений.

Это изменение не решает проблему, а эмулирует её решение. Т.е. - люди будут страдать как и раньше, но реже.

Надо решить проблему нормальным способом.

> 
> Кроме того, ждать появления того, что явно прописано в конфиге -- нормальная
> практика. Не будем забывать, что тот же event driven systemd ждёт появления
> диска, прописанного в fstab 2 минуты. 2 минуты, а не 2 секунды!

Мне не нужна задержка инициализации сети на 2 секунды на отсутствующий интерфейс по умолчанию.

(Ответ для Anton Farygin на комментарий #21)
> (Ответ для Anton V. Boyarshinov на комментарий #20)
> > > Это ошибочное изменение, на самом деле надо инициализировать через сервис
> > > systemd для etcnet - и об этом сказано в документации на wiki.
> > > 
> > > systemctl enable enp0s3@network
> > 
> > Это изменение не противоречит документации на wiki и не мешает пользоваться
> > решением через systemctl enable enp0s3@network и другими возможными. Однако,
> > оно позволяет обеспечить работоспособность сети после обновления без
> > дополнительных телодвижений.
> 
> Это изменение не решает проблему, а эмулирует её решение. Т.е. - люди будут
> страдать как и раньше, но реже.
> 
> Надо решить проблему нормальным способом.

Одно другому не противоречит.

> > Кроме того, ждать появления того, что явно прописано в конфиге -- нормальная
> > практика. Не будем забывать, что тот же event driven systemd ждёт появления
> > диска, прописанного в fstab 2 минуты. 2 минуты, а не 2 секунды!
> 
> Мне не нужна задержка инициализации сети на 2 секунды на отсутствующий
> интерфейс по умолчанию.

При запуске "правильным способом" через network@.service эта проблема не должна проявляться. И таймаут настраивается, поставь 0.

Антон, таймаут приедет с обновлением, его невозможно отследить и поставить везде в ноль.

Я не понял, почему таймаут не должен проявляться при выключении сервиса ?

(Ответ для Anton Farygin на комментарий #23)
> Антон, таймаут приедет с обновлением, его невозможно отследить и поставить
> везде в ноль.
> 
> Я не понял, почему таймаут не должен проявляться при выключении сервиса ?

если ты будешь запускать отдельные интерфейсы через network@ и эти интерфейсы всегда будут на месте -- не вижу где возникнет таймаут

запуск через @.network не означает что интерфейс будет отсутствовать в /etc/net и не будет срабатывать таймаут.

А почему такой маленький дефолтный тайм-аут? Не стоит ли его увеличить до 5-7 секунд?

(In reply to Anton Farygin from comment #25)
> запуск через @.network не означает что интерфейс будет отсутствовать в
> /etc/net и не будет срабатывать таймаут.

Запуск через network@ означает, что для интерфейса будет ONBOOT=no. Откуда таймаут?

одно другому не мешает.

Предлагаю пока проверить пакет Михаила т использовать как workaround, но багу не закрывать и активно над ней работать. В первую очередь обращая внимание на обновление.

workaround уже есть, я им пользуюсь. не надо придумывать других.

(Ответ для Anton Farygin на комментарий #30)
> workaround уже есть, я им пользуюсь. не надо придумывать других.

На усмотрение мейнтейнера и релиз-менеджера. 
Здесь были разные мнения.

(In reply to Ivan A. Melnikov from comment #27)
> (In reply to Anton Farygin from comment #25)
> > запуск через @.network не означает что интерфейс будет отсутствовать в
> > /etc/net и не будет срабатывать таймаут.
> 
> Запуск через network@ означает, что для интерфейса будет ONBOOT=no. Откуда таймаут?

+1

(Ответ для Anton Farygin на комментарий #30)
> workaround уже есть, я им пользуюсь. не надо придумывать других.

Он работает автоматически или требует настройки? Вот этот workaround требует настройки чтоб его отключить и ты против. Хотя настраивать что-либо, имея доступ к машине по сети гораздо удобнее, чем когда он пропал.

Там же не задержка до поднятия интерфейса. Там таймаут ожидания его появления в sysfs:

http://git.altlinux.org/tasks/index/sisyphus/tested/284439/gears/100/git?p=git;a=blob;f=etc/net/scripts/network.init;h=c81561e43ad0d3c467392646361a62b3ba1041bc;hb=a9d821ccf960ea9bb749b188cdfc5c87dd41626d#l151

Так что этот код будет работать и с systemd без воркэраунда, и на sysvinit. Но какой смысл делать при таком коде задержку в 2 секудны!? Если поставить хоть 10, а интерфейс будет появляться за 1.5 секунды, тут не будет лишней задержки. Вот если интерфейс реально помер, то задержка будет и заметная при значении 5-7 секунд, но это допустимо увидеть тогда и в логах загрузки.

(In reply to Evgeny Sinelnikov from comment #10)
> (Ответ для Evgeny Sinelnikov на комментарий #1)
> > Установка udevd-final не помогает:
> > https://bugzilla.altlinux.org/show_bug.cgi?id=29282#c34
> 
> Значит так, тут всё несколько сложнее и интереснее. udevd-final - это имя,
> которое предоставляет пакет udev-rule-generator. Он проблему не решает.

У меня в стартеркитах проблему решило. Проблема была даже в virtualbox и со 100% вероятностью воспроизводилась.

И я разобрался сейчас почему:
Wants=systemd-udev-settle.service

Добавил в network.service и заработало без udevd-final.

(Ответ для Антон Мидюков на комментарий #35)
> (In reply to Evgeny Sinelnikov from comment #10)
> > (Ответ для Evgeny Sinelnikov на комментарий #1)
> > > Установка udevd-final не помогает:
> > > https://bugzilla.altlinux.org/show_bug.cgi?id=29282#c34
> > 
> > Значит так, тут всё несколько сложнее и интереснее. udevd-final - это имя,
> > которое предоставляет пакет udev-rule-generator. Он проблему не решает.
> 
> У меня в стартеркитах проблему решило. Проблема была даже в virtualbox и со
> 100% вероятностью воспроизводилась.
> 
> И я разобрался сейчас почему:
> Wants=systemd-udev-settle.service
> 
> Добавил в network.service и заработало без udevd-final.

Я всем про Wants=systemd-udev-settle.service уже говорил, но меня не слышат и пытаются строить велосипеды.

(Ответ для Alexey Shabalin на комментарий #36)
> (Ответ для Антон Мидюков на комментарий #35)
> > У меня в стартеркитах проблему решило. Проблема была даже в virtualbox и со
> > 100% вероятностью воспроизводилась.
> > 
> > И я разобрался сейчас почему:
> > Wants=systemd-udev-settle.service
> > 
> > Добавил в network.service и заработало без udevd-final.
> 
> Я всем про Wants=systemd-udev-settle.service уже говорил, но меня не слышат
> и пытаются строить велосипеды.

Т.е. systemd-udev-settle.service был просто выключен? Что-то я не догадался это проверить. Я помню про Wants, но из описания мне было совсем не очевидно, что это должно  как-то помогать. Там говорится лишь о том, что сервисы в Wants должны запускаться если запускается данный юнит, но порядок запуска задается только  с помощью After/Before. Я почему-то думал, что systemd-udev-settle.service и так активен.

After и Wants работают независимо друг от друга. After указывают кто первый будет стартовать, если они начнут стартовать вместе при параллельной загрузке. Т.е. может быть гонка.
А Wants это уже мягкая зависимость. А вместе After+Wants уже будут означать, что надо дождаться завершения загрузки юнита (starting -> started).

Предлагаю указать в network.service сдежующее:
Wants=systemd-udev-settle.service systemd-udev-trigger.service network-pre.target local-fs.target sysinit.target network.target

И к After добавить systemd-udev-trigger.service.

И еще, давайте это сделаем без добавления таймаутов. Этот костыль всегда можно приделать.

А еще предлагаю убрать network@.service.
Это тоже костыль, который не вписывается в идеологию и архитектуру etcnet.

(In reply to Alexey Shabalin from comment #39)
> И еще, давайте это сделаем без добавления таймаутов. Этот костыль всегда
> можно приделать.
systemd этот "костыль" никак не мешает, в идеальном случае таймаут равен нулю. А для новых ядер на sysvinit он всё равно нужен.

(In reply to Leonid Krivoshein from comment #41)
> (In reply to Alexey Shabalin from comment #39)
> > И еще, давайте это сделаем без добавления таймаутов. Этот костыль всегда
> > можно приделать.
> systemd этот "костыль" никак не мешает, в идеальном случае таймаут равен
> нулю. А для новых ядер на sysvinit он всё равно нужен.

На sysvinit без включенного udevd-final вообще иксы не работают. Картинка есть и всё. Ничего не работает.
А когда он включен, то и с сетью проблем нет. Я для sysvinit в m-p уже добавил обязательное включение udevd-final. И всё отлично.
Инсинуации про то, что проблема может быть на sysvinit не поддерживаю.
Проблема началась после выкидывания udev-rule-generator-net по причине того, что сеть перестала ждать, пока udevadm во всех своих вариантах до конца отработает.
Если окажется, что udevd-final для sysvinit недостаточно, то нужно не тайм-аут ставить, а чинить udevd-final под реалии нового udev.
Но, может нужно доделать /etc/rc.d/init.d/udevd, чтобы он не завершал работу, пока инициализация устройств не закончится. Тогда и udevd-final нужен не будет.

(Ответ для Антон Мидюков на комментарий #42)
...
> Если окажется, что udevd-final для sysvinit недостаточно, то нужно не
> тайм-аут ставить, а чинить udevd-final под реалии нового udev.
> Но, может нужно доделать /etc/rc.d/init.d/udevd, чтобы он не завершал
> работу, пока инициализация устройств не закончится. Тогда и udevd-final
> нужен не будет.

Давайте выработаем какую-то единую стратегию развития наших дистрибутивных решений, а то они выглядят, мягко говоря, весьма противоречиво.

О чём это я?

О том, что наблюдается две странных тенденции:
- в одних задачах мы тратим массу усилий для того, чтобы сократить процесс загрузки;
- в других оказывается, что это уже не так важно, поскольку что-то перестаёт работать, хотя по-началу этого никто даже и не заметил.

Например:
- с одной стороны у нас куча проблем с тем, что initrd делают небольшого размера с целью уменьшения времени загрузки;
- с другой - никого не смущает, что время загрузки на ожидании сети слиьно увеличивается для синхронизации.

А какой из этих вариантов более критичен для времени загрузки?
И, если окажется (а я думаю,Что так оно и есть), сеть более критична, а подождать секунд - это разумный компромисс, то почему для initrd правила другие?

(Ответ для Alexey Shabalin на комментарий #40)
> А еще предлагаю убрать network@.service.
> Это тоже костыль, который не вписывается в идеологию и архитектуру etcnet.

не не не, вот его точно не надо убирать.

(In reply to Evgeny Sinelnikov from comment #43)
> (Ответ для Антон Мидюков на комментарий #42)
> ...
> > Если окажется, что udevd-final для sysvinit недостаточно, то нужно не
> > тайм-аут ставить, а чинить udevd-final под реалии нового udev.
> > Но, может нужно доделать /etc/rc.d/init.d/udevd, чтобы он не завершал
> > работу, пока инициализация устройств не закончится. Тогда и udevd-final
> > нужен не будет.
> 
> Давайте выработаем какую-то единую стратегию развития наших дистрибутивных
> решений, а то они выглядят, мягко говоря, весьма противоречиво.

Не в этой же баге? Есть рассылка devel-distro@. Давайте там это обсудим.

> - с одной стороны у нас куча проблем с тем, что initrd делают небольшого
> размера с целью уменьшения времени загрузки;
> - с другой - никого не смущает, что время загрузки на ожидании сети слиьно
> увеличивается для синхронизации.
Где оно сильно увеличивается? Оно увеличивается только в случае, если настроенного интерфейса (пока) нет. Точно также происходит и в initrd -- пока устройство, на котором / не появится -- загрузка дальше не пойдет.

(Ответ для Anton V. Boyarshinov на комментарий #46)
> > - с одной стороны у нас куча проблем с тем, что initrd делают небольшого
> > размера с целью уменьшения времени загрузки;
> > - с другой - никого не смущает, что время загрузки на ожидании сети слиьно
> > увеличивается для синхронизации.
> Где оно сильно увеличивается? Оно увеличивается только в случае, если
> настроенного интерфейса (пока) нет. Точно также происходит и в initrd --
> пока устройство, на котором / не появится -- загрузка дальше не пойдет.

увеличится, если у тебя в конфиге написана лажа - сейчас в /etc/net можно безболезненно держать каталоги несуществующих интерфейсов.

и такое повсеместно встречается на серверах.

(Ответ для Anton Farygin на комментарий #47)
> (Ответ для Anton V. Boyarshinov на комментарий #46)
> > > - с одной стороны у нас куча проблем с тем, что initrd делают небольшого
> > > размера с целью уменьшения времени загрузки;
> > > - с другой - никого не смущает, что время загрузки на ожидании сети слиьно
> > > увеличивается для синхронизации.
> > Где оно сильно увеличивается? Оно увеличивается только в случае, если
> > настроенного интерфейса (пока) нет. Точно также происходит и в initrd --
> > пока устройство, на котором / не появится -- загрузка дальше не пойдет.
> 
> увеличится, если у тебя в конфиге написана лажа

То есть возможность держать лажу в конфигах важнее работоспособности?

> на серверах такое встречается повсеместно

Железные сервера запускаются так долго, что даже десяток-другой секунд роли не играет.

это у вас долго, а у меня виртуалки перезагружаются за секунду.

(In reply to Anton Farygin from comment #47)
> увеличится, если у тебя в конфиге написана лажа - сейчас в /etc/net можно
> безболезненно держать каталоги несуществующих интерфейсов.
Если в конфиге написана лажа, интерфейс всё равно не поднимется, независимо от дополнительной задержки, к тому же это проблема конфига и криворукости админа. Сомневаюсь, что etcnet нужна фича игнорирования ошибочных конфигов, скорее это способ подчеркнуть, что есть проблема с конфигом.

Другое дело, что выше предложено решение, возможно более правильное, через исправление зависимостей systemd.

Вообще конечно нет, это не проблема криворукости админа. Это стандартная ситуация - у нас после установки создаются каталоги для всех существующих интерфейсов. А потом эти интерфейсы меняют имена.

Исправление зависимостей systemd надо обдумать, возможно оно и действительно правильное, но задержки внесёт в процесс загрузки ещё более высокие.

(In reply to Anton Farygin from comment #51)
> Вообще конечно нет, это не проблема криворукости админа. Это стандартная
> ситуация - у нас после установки создаются каталоги для всех существующих
> интерфейсов. А потом эти интерфейсы меняют имена.

А почему они меняют имена?

> 
> Исправление зависимостей systemd надо обдумать, возможно оно и действительно
> правильное, но задержки внесёт в процесс загрузки ещё более высокие.

Сделал замер в virtualbox. Минимальная установка сервера-стартеркита с systemd. Без Wants userspace грузится чуть более 1 секунды (интерфейс не поднимается). После добавления Wants 6-7 секунд.
Максимальная установка сервера с systemd. Без Wants userspace грузится 6-7 секунд (интерфейс поднимается). После добавления Wants 7-8 секунд.
Интересно сделать замеры на реальном железе. На виртуалке ничего страшного.

(In reply to Антон Мидюков from comment #52)
> Максимальная установка сервера с systemd. Без Wants userspace грузится 6-7
> секунд (интерфейс поднимается). После добавления Wants 7-8 секунд.

Нет, результат не отличается от минимальной установки. Забыл выключить udevd-final.service

(Ответ для Антон Мидюков на комментарий #52)
> (In reply to Anton Farygin from comment #51)
> > Вообще конечно нет, это не проблема криворукости админа. Это стандартная
> > ситуация - у нас после установки создаются каталоги для всех существующих
> > интерфейсов. А потом эти интерфейсы меняют имена.
> 
> А почему они меняют имена?

Да по разным причинам, начиная от изменений в systemd и заканчивая установкой других устройств.

> 
> > 
> > Исправление зависимостей systemd надо обдумать, возможно оно и действительно
> > правильное, но задержки внесёт в процесс загрузки ещё более высокие.
> 
> Сделал замер в virtualbox. Минимальная установка сервера-стартеркита с
> systemd. Без Wants userspace грузится чуть более 1 секунды (интерфейс не
> поднимается). После добавления Wants 6-7 секунд.
> Максимальная установка сервера с systemd. Без Wants userspace грузится 6-7
> секунд (интерфейс поднимается). После добавления Wants 7-8 секунд.
> Интересно сделать замеры на реальном железе. На виртуалке ничего страшного.

Это вообще не то, надо замерять на железе, на котором медленно поднимаются сетевые адаптеры. 

А проблему то это решает ?

(In reply to Anton Farygin from comment #54)
> А проблему то это решает ?

Решает. Не запускаем network.service, пока не закончится инициализация устройств.
До 9.2 (в некоторых дистрибутивах раньше?) у нас был включен udev-rule-generator-net, и никто на скорость загрузки не жаловался. Но жаловались на скачок номера интерфейса после установки. Выкинули udev-rule-generator-net и поймали проблемы с тем, что на момент запуска network.service сетевые интерфейсы не готовы. То есть, раньше мы всегда дожидались завершения инициализации всех устройств перед стартом network.service. И данное решение предлагает сделать как раньше, но интерфейсы не переименовывать во избежание скачка их нумерации после установки.

Если мы хотим быструю загрузку до завершения инициализации всех устройств, то требуется или доработать etcnet, либо заменить его на systemd-networkd и NetworkManager. В десктопных дистрибутивах, кстати, network.service можно будет отключить для ускорения загрузки.

Антон, спасибо за исследование.

Да, наверное это сейчас оптимальный вариант.

(Ответ для Alexey Shabalin на комментарий #38)
> After и Wants работают независимо друг от друга. After указывают кто первый
> будет стартовать, если они начнут стартовать вместе при параллельной
> загрузке. Т.е. может быть гонка.
> А Wants это уже мягкая зависимость. А вместе After+Wants уже будут означать,
> что надо дождаться завершения загрузки юнита (starting -> started).
> 
> Предлагаю указать в network.service сдежующее:
> Wants=systemd-udev-settle.service systemd-udev-trigger.service
> network-pre.target local-fs.target sysinit.target network.target
> 
> И к After добавить systemd-udev-trigger.service.

Сделал эти изменения, похоже работает. На sysvinit сервис udev тоже ждет конца инициализации, так что workaround с таймаутом теряет всякий смысл.
В #284827 новая сборка.

Спасибо. Отправьте ещё в p9, пожалуйста.

etcnet-0.9.21-alt1 -> sisyphus:

 Wed Sep 08 2021 Mikhail Efremov <sem@altlinux> 0.9.21-alt1
 - Don't use deprecated PreReq.
 - systemd: Fixed network.service dependencies (closes: #40780).

Спасибо!