Bug 40780

Summary: Не инициализируется на старте сетевой интерфейс
Product: Sisyphus Reporter: Anton Protopopov <antoniopost>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: major    
Priority: P5 CC: aen, antohami, asheplyakov, boyarsh, iv, klark, ldv, mike, nir, rider, sem, shaba, shadowsbrother, sin, vseleznv
Version: unstable   
Hardware: x86_64   
OS: Linux   
Attachments:
Description Flags
Лог загрузки none

Description Anton Protopopov 2021-08-18 18:31:08 MSK
Created attachment 9610 [details]
Лог загрузки

После установки операционной системы Workstation 9.2 не инициализируется переименнованный ядром сетевой интерфейс enp0s3.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:b3:2d:f4 brd ff:ff:ff:ff:ff:ff

Проблема восопроизводится как на виртуалке в VirtualBox'е, так и на железе, но менее часто. И, обычно, решается последующей переинициализацией интерфейса NetworkManager'ом после загрузки.

__________________________

Из лога загрузки видно, что службы network и NetworkManager (в данном случае не существенно) отрабатывают намного раньше, чем переименование интерфейса ядром:
kernel: e1000 0000:00:03.0 enp0s3: renamed from eth0

Настройки etcnet:

# ls /etc/net/ifaces/
default  enp0s3  lo  unknown

# cat /etc/net/ifaces/enp0s3/options 
TYPE=eth
CONFIG_WIRELESS=no
BOOTPROTO=dhcp
CONFIG_IPV4=yes
DISABLED=no
NM_CONTROLLED=no

Краткий вывод лога загрузки (полный в приложении) командой journalctl --boot:

- Logs begin at Wed 2021-08-18 17:54:05 MSK, end at Wed 2021-08-18 18:02:39 MSK. --
авг 18 18:01:08 c245 kernel: Linux version 5.10.52-un-def-alt1 (builder@localhost.localdomain) (gcc-8 (GCC) 8.4.1 20200305 (ALT p9 8.4.1-alt0.p9.1), GNU ld (GNU Binutils) 2.31.1.20181202) #1 SMP PREEMPT Wed Jul 21 10:14:40 UTC 2021
авг 18 18:01:08 c245 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz root=UUID=768c9da6-3abc-431a-9a9a-c5530b929033 ro vga=0x314 quiet panic=30 splash
авг 18 18:01:08 c245 kernel: KERNEL supported cpus:
авг 18 18:01:08 c245 kernel:   Intel GenuineIntel
авг 18 18:01:08 c245 kernel:   AMD AuthenticAMD
авг 18 18:01:08 c245 kernel:   Hygon HygonGenuine
авг 18 18:01:08 c245 kernel:   Centaur CentaurHauls
...
авг 18 18:01:08 c245 systemd[1]: Detected virtualization oracle.
авг 18 18:01:08 c245 systemd[1]: Detected architecture x86-64.
авг 18 18:01:08 c245 systemd[1]: Set hostname to <c245>.
...
авг 18 18:01:09 c245 network[2116]: Computing interface groups: .. 2 interfaces found
авг 18 18:01:09 c245 network[2116]: Starting group 0/virtual (1 interfaces)
...
авг 18 18:01:09 c245 network[2116]:         Starting lo:
авг 18 18:01:09 c245 network[2175]:  'lo' is already up
авг 18 18:01:09 c245 network[2116]: SKIPPED
...
авг 18 18:01:09 c245 network[2116]: Starting group 1/realphys (1 interfaces)
авг 18 18:01:09 c245 systemd[1]: Started Modem Manager.
...
авг 18 18:01:09 c245 network[2116]:         Starting enp0s3:
авг 18 18:01:09 c245 network[2215]: Cannot find device "enp0s3"
авг 18 18:01:09 c245 network[2201]: .
авг 18 18:01:09 c245 network[2219]: Cannot find device "enp0s3"
авг 18 18:01:09 c245 kernel: piix4_smbus 0000:00:07.0: SMBus Host Controller at 0x4100, revision 0
авг 18 18:01:09 c245 network[2222]: .
авг 18 18:01:09 c245 network[2218]: .
авг 18 18:01:09 c245 network[2116]: OK
авг 18 18:01:09 c245 network[2116]: Processing /etc/net/vlantab: empty.
...
авг 18 18:01:09 c245 NetworkManager-prestart[2254]: Setting network parameters: succeeded
авг 18 18:01:09 c245 NetworkManager-prestart[2247]: Setting network parameters: [ DONE ]
...
авг 18 18:01:09 c245 NetworkManager[2258]: <info>  [1629298869.9595] NetworkManager (version 1.18.11-alt1.gite2fdbc2b7482) is starting... (for the first time)
авг 18 18:01:09 c245 NetworkManager[2258]: <info>  [1629298869.9598] Read config: /etc/NetworkManager/NetworkManager.conf (lib: 31-mac-addr-change.conf)
авг 18 18:01:09 c245 systemd[1]: Started Network Manager.
авг 18 18:01:09 c245 systemd[1]: Reached target Network.
...
авг 18 18:01:09 c245 NetworkManager[2258]: <info>  [1629298869.9736] bus-manager: acquired D-Bus service "org.freedesktop.NetworkManager"
авг 18 18:01:09 c245 kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input6
авг 18 18:01:09 c245 NetworkManager[2258]: <info>  [1629298869.9768] manager[0x55c81d9ed090]: monitoring kernel firmware directory '/lib/firmware'.
...
авг 18 18:01:10 c245 NetworkManager[2258]: <info>  [1629298870.5542] hostname: hostname: using hostnamed
авг 18 18:01:10 c245 NetworkManager[2258]: <info>  [1629298870.5542] hostname: hostname changed from (none) to "c245"
авг 18 18:01:10 c245 NetworkManager[2258]: <info>  [1629298870.5544] dns-mgr[0x55c81d9ca210]: init: dns=default,systemd-resolved rc-manager=resolvconf
...
авг 18 18:01:11 c245 NetworkManager[2258]: <info>  [1629298871.0092] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/2)
авг 18 18:01:11 c245 kernel: e1000 0000:00:03.0 eth0: (PCI:33MHz:32-bit) 08:00:27:b3:2d:f4
авг 18 18:01:11 c245 kernel: e1000 0000:00:03.0 eth0: Intel(R) PRO/1000 Network Connection
авг 18 18:01:11 c245 systemd-udevd[2093]: Using default interface naming scheme 'v245'.
авг 18 18:01:11 c245 systemd-udevd[2093]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
авг 18 18:01:11 c245 kernel: e1000 0000:00:03.0 enp0s3: renamed from eth0
авг 18 18:01:11 c245 NetworkManager[2258]: <info>  [1629298871.0153] device (eth0): interface index 2 renamed iface from 'eth0' to 'enp0s3'
авг 18 18:01:11 c245 systemd[1]: Started User Database Manager.
авг 18 18:01:11 c245 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-userdbd comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
авг 18 18:01:11 c245 NetworkManager[2258]: <info>  [1629298871.0223] etcnet-alt: Device enp0s3 is unmanaged
...
Comment 1 Evgeny Sinelnikov 2021-08-24 23:08:47 MSK
Установка udevd-final не помогает:
https://bugzilla.altlinux.org/show_bug.cgi?id=29282#c34

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

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

На самом деле, об этой проблеме я уже сообщал (год назад):
https://bugzilla.altlinux.org/38774
Comment 2 Evgeny Sinelnikov 2021-08-24 23:10:42 MSK
*** Bug 38774 has been marked as a duplicate of this bug. ***
Comment 3 Leonid Krivoshein 2021-08-25 00:44:15 MSK
Помогает ли рекомендация из статьи про Etcnet:

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

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

Я раньше рекомендовал при подобных гонках добавлять MODULE=... в options-файл интерфейса, что заставляло etcnet перед запуском сделать для него modprobe. Но у этого подхода есть обратная сторона медали: при перезапуске сети модуль выгружается, а если модуль один на несколько интерфейсов, может быть не очень хорошо. Новый вариант с юнитом systemd, возможно, пора сделать дефолтным для дистрибутивов на основе systemd.
Comment 4 Alexey Shabalin 2021-08-25 02:33:33 MSK
(Ответ для Leonid Krivoshein на комментарий #3)
> Новый вариант с юнитом systemd,
> возможно, пора сделать дефолтным для дистрибутивов на основе systemd.

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

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

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

> С юнитом надо рекомендовать переход на systemd-networkd.
Тоже вариант, но его ещё надо реализовывать, и если пользователь выбирает не этот вариант, проблема всё равно должна решаться.
Comment 6 Alexey Shabalin 2021-08-25 03:05:19 MSK
(Ответ для Leonid Krivoshein на комментарий #5)
> (In reply to Alexey Shabalin from comment #4)
> > Пожалуйста, не надо этот вариант делать по-умолчанию. Я бы даже не стал
> > рекомендовать :)
> Речь о том, что при установке выбран etcnet, есть "гонки" и есть рабочий
> workaround. Это и есть суть ремонта etcnet, должно "из коробки" работать.

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


Ла, конечно.
Но нам нужно дать рекомендации и тем пользователям, которые не дождутся окончания правильного ремонта.
Comment 8 Leonid Krivoshein 2021-08-25 04:15:23 MSK
(In reply to Alexey Shabalin from comment #6)
> Вот я и говорю, не надо workaround (костыль) делать по-умолчанию. Надо
> чинить, а не мусор под коврик заметать. Этот workaround совсем не суть
> ремонта.
Написанное можно воспринимать по-разному. :-) Etcnet как служба многим нравится, но архитектурно она не часть systemd и изначально не рассчитывалась на работу в его окружении. Указанный юнит и есть суть ремонта, т.к. единственный способ интегрировать конкретный интерфейс с systemd при желании не гоняться с моментом запуска etcnet. А суть ремонта в твоём понимании -- выкорчёвывать etcnet из дистрибутива и переходить полностью на systemd-networkd? И только это предлагать по умолчанию? Или какой вариант ремонта etcnet тут ещё возможен?
Comment 9 AEN 2021-08-25 04:25:54 MSK
Замечу только, что "предлагать по умолчанию" не значит не предлагать альтернативы.
1. Так как проблема серьезная, то мне кажется, что стоит скорее вынести ее в отдельную статью вики с описанием, что можно сделать сейчас, и сослаться на эту статью в описании продуктов.
2. Я бы подождал sem@ для обсуждения окончательного решения по исправлению баги, он будет в понедельник.
Comment 10 Evgeny Sinelnikov 2021-08-30 03:17:58 MSK
(Ответ для 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 отсутствовал на стадии загрузки).
Comment 11 Evgeny Sinelnikov 2021-08-30 03:31:36 MSK
Не важно переименован интерфейс ядром или нет. Даже наоборот, если интерфейс переименуется через udev-rule-generator-net и прописан в правилах etcnet, то проблема не возникает.
Comment 12 Evgeny Sinelnikov 2021-08-30 03:58:54 MSK
Для статических адресов, настроенных через 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 будет переименован.
Comment 13 Mikhail Efremov 2021-09-02 19:55:35 MSK
В таске #284439 сервис network будет ждать появления интерфейса перед запуском ifup, по умолчанию 2 секунды. Просьба проверить, у меня работает.
Comment 14 Anton Farygin 2021-09-02 21:10:13 MSK
(Ответ для Mikhail Efremov на комментарий #13)
> В таске #284439 сервис network будет ждать появления интерфейса перед
> запуском ifup, по умолчанию 2 секунды. Просьба проверить, у меня работает.

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

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

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

Документацию на вики можно дополнить.
Comment 16 Anton Farygin 2021-09-02 21:20:40 MSK
Ошибка в том, что появился параметр таймаута, который в реальной жизни не нужен - мы никогда не сможем предугадать его значение так, что бы оно устраивало всех пользователей.

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

Возможно, стоит сделать универсальный сервис, реагирующий на появлению любого интерфейса в системе и запускающий ifup из etcnet для него при наличии конфига. Но последствия такого сервиса надо хорошенько обдумать, возможно он будет не всегда полезен. Хотя NetworkManager, на самом деле, является аналогом именно такого сервиса.
Comment 17 Evgeny Sinelnikov 2021-09-02 21:56:59 MSK
(Ответ для Anton Farygin на комментарий #16)
> Ошибка в том, что появился параметр таймаута, который в реальной жизни не
> нужен - мы никогда не сможем предугадать его значение так, что бы оно
> устраивало всех пользователей.

Именно.

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

Согласен.

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

Да, как раз такой сервис мы уже с Алексеем и запланировали в общих чертах.
Это похоже на systemd-networkd на shell'е или для shell'а, но именно такую
архитекуру мы и задумали для старта и поддержки etcnet.
Comment 18 Mikhail Efremov 2021-09-02 22:05:29 MSK
(Ответ для Anton Farygin на комментарий #14)
> systemctl enable enp0s3@network

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

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

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

Т.е. - в данном случае systemd отрабатывает в качестве удобного инструмента для запуска скрипта, но в старой жизни этот же функционал можно сделать и другими способами.
Comment 20 Anton V. Boyarshinov 2021-09-03 11:00:51 MSK
> Это ошибочное изменение, на самом деле надо инициализировать через сервис
> systemd для etcnet - и об этом сказано в документации на wiki.
> 
> systemctl enable enp0s3@network

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

Кроме того, ждать появления того, что явно прописано в конфиге -- нормальная практика. Не будем забывать, что тот же event driven systemd ждёт появления диска, прописанного в fstab 2 минуты. 2 минуты, а не 2 секунды!
Comment 21 Anton Farygin 2021-09-03 11:04:40 MSK
(Ответ для Anton V. Boyarshinov на комментарий #20)
> > Это ошибочное изменение, на самом деле надо инициализировать через сервис
> > systemd для etcnet - и об этом сказано в документации на wiki.
> > 
> > systemctl enable enp0s3@network
> 
> Это изменение не противоречит документации на wiki и не мешает пользоваться
> решением через systemctl enable enp0s3@network и другими возможными. Однако,
> оно позволяет обеспечить работоспособность сети после обновления без
> дополнительных телодвижений.

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

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

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

Мне не нужна задержка инициализации сети на 2 секунды на отсутствующий интерфейс по умолчанию.
Comment 22 Anton V. Boyarshinov 2021-09-03 11:12:18 MSK
(Ответ для 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.
Comment 23 Anton Farygin 2021-09-03 11:16:13 MSK
Антон, таймаут приедет с обновлением, его невозможно отследить и поставить везде в ноль.

Я не понял, почему таймаут не должен проявляться при выключении сервиса ?
Comment 24 Anton V. Boyarshinov 2021-09-03 12:06:15 MSK
(Ответ для Anton Farygin на комментарий #23)
> Антон, таймаут приедет с обновлением, его невозможно отследить и поставить
> везде в ноль.
> 
> Я не понял, почему таймаут не должен проявляться при выключении сервиса ?

если ты будешь запускать отдельные интерфейсы через network@ и эти интерфейсы всегда будут на месте -- не вижу где возникнет таймаут
Comment 25 Anton Farygin 2021-09-03 12:19:20 MSK
запуск через @.network не означает что интерфейс будет отсутствовать в /etc/net и не будет срабатывать таймаут.
Comment 26 Leonid Krivoshein 2021-09-03 12:26:51 MSK
А почему такой маленький дефолтный тайм-аут? Не стоит ли его увеличить до 5-7 секунд?
Comment 27 Ivan A. Melnikov 2021-09-03 12:32:20 MSK
(In reply to Anton Farygin from comment #25)
> запуск через @.network не означает что интерфейс будет отсутствовать в
> /etc/net и не будет срабатывать таймаут.

Запуск через network@ означает, что для интерфейса будет ONBOOT=no. Откуда таймаут?
Comment 28 Anton Farygin 2021-09-03 13:13:36 MSK
одно другому не мешает.
Comment 29 AEN 2021-09-03 14:08:32 MSK
Предлагаю пока проверить пакет Михаила т использовать как workaround, но багу не закрывать и активно над ней работать. В первую очередь обращая внимание на обновление.
Comment 30 Anton Farygin 2021-09-03 14:09:31 MSK
workaround уже есть, я им пользуюсь. не надо придумывать других.
Comment 31 AEN 2021-09-03 14:12:54 MSK
(Ответ для Anton Farygin на комментарий #30)
> workaround уже есть, я им пользуюсь. не надо придумывать других.

На усмотрение мейнтейнера и релиз-менеджера. 
Здесь были разные мнения.
Comment 32 Dmitry V. Levin 2021-09-03 14:51:59 MSK
(In reply to Ivan A. Melnikov from comment #27)
> (In reply to Anton Farygin from comment #25)
> > запуск через @.network не означает что интерфейс будет отсутствовать в
> > /etc/net и не будет срабатывать таймаут.
> 
> Запуск через network@ означает, что для интерфейса будет ONBOOT=no. Откуда таймаут?

+1
Comment 33 Anton V. Boyarshinov 2021-09-03 15:38:15 MSK
(Ответ для Anton Farygin на комментарий #30)
> workaround уже есть, я им пользуюсь. не надо придумывать других.

Он работает автоматически или требует настройки? Вот этот workaround требует настройки чтоб его отключить и ты против. Хотя настраивать что-либо, имея доступ к машине по сети гораздо удобнее, чем когда он пропал.
Comment 34 Leonid Krivoshein 2021-09-03 17:47:00 MSK
Там же не задержка до поднятия интерфейса. Там таймаут ожидания его появления в 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 секунд, но это допустимо увидеть тогда и в логах загрузки.
Comment 35 Антон Мидюков 2021-09-03 19:37:46 MSK
(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.
Comment 36 Alexey Shabalin 2021-09-03 19:52:08 MSK
(Ответ для Антон Мидюков на комментарий #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 уже говорил, но меня не слышат и пытаются строить велосипеды.
Comment 37 Mikhail Efremov 2021-09-03 22:33:13 MSK
(Ответ для 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 и так активен.
Comment 38 Alexey Shabalin 2021-09-04 00:12:19 MSK
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.
Comment 39 Alexey Shabalin 2021-09-04 00:14:15 MSK
И еще, давайте это сделаем без добавления таймаутов. Этот костыль всегда можно приделать.
Comment 40 Alexey Shabalin 2021-09-04 00:16:27 MSK
А еще предлагаю убрать network@.service.
Это тоже костыль, который не вписывается в идеологию и архитектуру etcnet.
Comment 41 Leonid Krivoshein 2021-09-04 03:40:21 MSK
(In reply to Alexey Shabalin from comment #39)
> И еще, давайте это сделаем без добавления таймаутов. Этот костыль всегда
> можно приделать.
systemd этот "костыль" никак не мешает, в идеальном случае таймаут равен нулю. А для новых ядер на sysvinit он всё равно нужен.
Comment 42 Антон Мидюков 2021-09-04 04:06:58 MSK
(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 нужен не будет.
Comment 43 Evgeny Sinelnikov 2021-09-04 05:23:29 MSK
(Ответ для Антон Мидюков на комментарий #42)
...
> Если окажется, что udevd-final для sysvinit недостаточно, то нужно не
> тайм-аут ставить, а чинить udevd-final под реалии нового udev.
> Но, может нужно доделать /etc/rc.d/init.d/udevd, чтобы он не завершал
> работу, пока инициализация устройств не закончится. Тогда и udevd-final
> нужен не будет.

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

О чём это я?

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

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

А какой из этих вариантов более критичен для времени загрузки?
И, если окажется (а я думаю,Что так оно и есть), сеть более критична, а подождать секунд - это разумный компромисс, то почему для initrd правила другие?
Comment 44 Anton Farygin 2021-09-04 11:59:44 MSK
(Ответ для Alexey Shabalin на комментарий #40)
> А еще предлагаю убрать network@.service.
> Это тоже костыль, который не вписывается в идеологию и архитектуру etcnet.

не не не, вот его точно не надо убирать.
Comment 45 Антон Мидюков 2021-09-05 19:29:28 MSK
(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@. Давайте там это обсудим.
Comment 46 Anton V. Boyarshinov 2021-09-06 11:26:45 MSK
> - с одной стороны у нас куча проблем с тем, что initrd делают небольшого
> размера с целью уменьшения времени загрузки;
> - с другой - никого не смущает, что время загрузки на ожидании сети слиьно
> увеличивается для синхронизации.
Где оно сильно увеличивается? Оно увеличивается только в случае, если настроенного интерфейса (пока) нет. Точно также происходит и в initrd -- пока устройство, на котором / не появится -- загрузка дальше не пойдет.
Comment 47 Anton Farygin 2021-09-06 11:34:27 MSK
(Ответ для Anton V. Boyarshinov на комментарий #46)
> > - с одной стороны у нас куча проблем с тем, что initrd делают небольшого
> > размера с целью уменьшения времени загрузки;
> > - с другой - никого не смущает, что время загрузки на ожидании сети слиьно
> > увеличивается для синхронизации.
> Где оно сильно увеличивается? Оно увеличивается только в случае, если
> настроенного интерфейса (пока) нет. Точно также происходит и в initrd --
> пока устройство, на котором / не появится -- загрузка дальше не пойдет.

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

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

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

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

Железные сервера запускаются так долго, что даже десяток-другой секунд роли не играет.
Comment 49 Anton Farygin 2021-09-06 13:39:56 MSK
это у вас долго, а у меня виртуалки перезагружаются за секунду.
Comment 50 Leonid Krivoshein 2021-09-06 17:17:00 MSK
(In reply to Anton Farygin from comment #47)
> увеличится, если у тебя в конфиге написана лажа - сейчас в /etc/net можно
> безболезненно держать каталоги несуществующих интерфейсов.
Если в конфиге написана лажа, интерфейс всё равно не поднимется, независимо от дополнительной задержки, к тому же это проблема конфига и криворукости админа. Сомневаюсь, что etcnet нужна фича игнорирования ошибочных конфигов, скорее это способ подчеркнуть, что есть проблема с конфигом.

Другое дело, что выше предложено решение, возможно более правильное, через исправление зависимостей systemd.
Comment 51 Anton Farygin 2021-09-06 19:15:20 MSK
Вообще конечно нет, это не проблема криворукости админа. Это стандартная ситуация - у нас после установки создаются каталоги для всех существующих интерфейсов. А потом эти интерфейсы меняют имена.

Исправление зависимостей systemd надо обдумать, возможно оно и действительно правильное, но задержки внесёт в процесс загрузки ещё более высокие.
Comment 52 Антон Мидюков 2021-09-06 19:58:02 MSK
(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 секунд.
Интересно сделать замеры на реальном железе. На виртуалке ничего страшного.
Comment 53 Антон Мидюков 2021-09-06 20:40:23 MSK
(In reply to Антон Мидюков from comment #52)
> Максимальная установка сервера с systemd. Без Wants userspace грузится 6-7
> секунд (интерфейс поднимается). После добавления Wants 7-8 секунд.

Нет, результат не отличается от минимальной установки. Забыл выключить udevd-final.service
Comment 54 Anton Farygin 2021-09-07 07:47:45 MSK
(Ответ для Антон Мидюков на комментарий #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 секунд.
> Интересно сделать замеры на реальном железе. На виртуалке ничего страшного.

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

А проблему то это решает ?
Comment 55 Антон Мидюков 2021-09-07 08:45:57 MSK
(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 можно будет отключить для ускорения загрузки.
Comment 56 Anton Farygin 2021-09-07 09:24:34 MSK
Антон, спасибо за исследование.

Да, наверное это сейчас оптимальный вариант.
Comment 57 Mikhail Efremov 2021-09-08 13:13:03 MSK
(Ответ для 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 новая сборка.
Comment 58 Anton Farygin 2021-09-08 13:22:30 MSK
Спасибо. Отправьте ещё в p9, пожалуйста.
Comment 59 Repository Robot 2021-09-08 15:43:01 MSK
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).
Comment 60 AEN 2021-09-08 15:46:39 MSK
Спасибо!