Bug 19313

Обновление версии ifrename не помогает.

Смену ядра - не пробовал (сейчас alt14 из branch/5.0).

Валера, а udev тут может как-то зафиксить этот вопрос ?
запускать ifrename только тогда, когда поток сетевых интерфейсов иссякнет ?

Кажется такое невозможно.

переименовывай во что нибудь отличное от ethX. других бесграбельных вариантов нет

Это к Стасу в alterator-network.

Впрочем, /etc/net/iftab сейчас тоже сломан, но там уже есть работающий патч:
https://bugzilla.altlinux.org/show_bug.cgi?id=11786

Получил лог (ifrename --verbose) в момент некорректного переименовывания. Вот что происходит:
--------запуск для eth1, идет перед eth0 в логе!!! -----------
Parsing : Added Mapping `eth0' from line 1.
Parsing : Added exact MAC address `00:07:e9:0a:46:72' from line 1.
Parsing : Added Mapping `eth1' from line 2.
Parsing : Added exact MAC address `00:0e:a6:5c:01:a0' from line 2.
Querying eth0 : Got MAC address `00:0E:A6:5C:01:A0' and ARP/Link Type `1'.
Takeover : moving interface `eth1' to `eth%d'.
-------------------

Запуск номер 2 в логе:
-------------------
Parsing : Added Mapping `eth0' from line 1.
Parsing : Added exact MAC address `00:07:e9:0a:46:72' from line 1.
Parsing : Added Mapping `eth1' from line 2.
Parsing : Added exact MAC address `00:0e:a6:5c:01:a0' from line 2.
Querying eth1 : Got MAC address `00:0E:A6:5C:01:A0' and ARP/Link Type `1'.
Setting : Interface `eth1' already matches `eth1'.
Error: cannot change name of eth0 to eth1: No such device
--------------------

Последний Error, по ощущением - от первого запуска ifrename.
Собственно вопрос:
- почему пришло уведомление сначала об eth1, потом об eth0 ?


Ну и что произошло, на русском:
- пришло уведомление о том, что появился интерфейс eth1, udev вызвает ifrename, который, пытаясь поменять eth1 на eth0 обнаруживает наличие eth0, меняет eth1 на eth2 (%d - это просто следующий свободный номер в ядре), и пытается eth0 переименовать в eth1. В это время, параллельно, другой процесс ifrename пытается так же eth0 перереименовать в eth1. Тут где-то засада и порылась. Видимо, кто-то из них успевает первее... и обламывается тот, который делал takeover в первом процессе, оставляя бывший eth1 как eth2. При этом eth0 у нас успешно переименован в eth1, и на выходе мы можем наблюдать наличие двух интерфейсов - eth1 и eth2.

Вопрос - как чинить ? Идеи есть ?

Сделать блокировку ? если запускается процесс takeover, то другой процесс ifrename ни в коем случае не должен трогать интерфейсы, для которых выполняется переименование... впрочем, видимо, это будет полезно и в других случаях.

(В ответ на комментарий №5)
> Ну и что произошло, на русском:
> - пришло уведомление о том, что появился интерфейс eth1, udev вызвает ifrename,
> который, пытаясь поменять eth1 на eth0 обнаруживает наличие eth0, меняет eth1
> на eth2 (%d - это просто следующий свободный номер в ядре), и пытается eth0
> переименовать в eth1.

Насколько я понимаю ifrename -u не меняет интерфейсы, он лишь говорит udev какое имя присвоить устройству... Правда, большой разницы это не делает в данном случае.

> Сделать блокировку ? если запускается процесс takeover, то другой процесс
> ifrename ни в коем случае не должен трогать интерфейсы, для которых выполняется
> переименование... впрочем, видимо, это будет полезно и в других случаях.

Нужно не вызывать ifrename напрямую из правила, а сделать скрипт-обёртку с блокировкой. Благо место для файловой блокировки есть.

Из того что ты нашёл следует, что эта проблема не зависит от #14837. Это рейс  ifrename.

Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать эти проблемы.

Assign => george@

Судя по коду в ядре - в качестве блокировки интерфейса от смены имени - можно говорить ему IFF_UP (т.е. - выставлять флаг в UP).

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

И да, эта проблема - race в связке udev/ядра/ifrename. Про это было сразу понятно.

Добавлю, что проблема воспроизводится на 5.0, а наши средства настройки активно используют /etc/iftab для привязки интерфейсов к мак-адресам. Соответственно, со всеми вытекающими последствиями в дистрибутивах.

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

$ ssh git.alt acl sisyphus wireless-tools show
wireless-tools	ldv george

$ rpmquery -p --lastchange --qf='%{packager}\n' ifrename-29-alt3.i586.rpm |sed -n 's/.*<\([^@]\+@\).*/\1/p' |uniq
george@

гм. я ничего специально не менял.

(В ответ на комментарий №11)
> гм. я ничего специально не менял.

Я знаю.

Created attachment 3394 [details]
ifrename-alt-lockfile.patch

На месте мантейнера, я не стал бы делать никаких скриптов, а добавил блокировку на конфигурационный файл. Как, например, в этом патче.

(In reply to comment #13)
> Created an attachment (id=3394) [details]
> ifrename-alt-lockfile.patch
> 
> На месте мантейнера, я не стал бы делать никаких скриптов, а добавил блокировку
> на конфигурационный файл. Как, например, в этом патче.

Спасибо, собрал 29-alt4 с этим патчем.

Спасибо, всё работает отлично!

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

Во-первых, в /etc/udev/rules.d/19-udev-ifrename.rules сейчас содержится

SUBSYSTEM=="net", ACTION=="add", PROGRAM="/sbin/ifrename -u -t -i %k", NAME="%k"

Это правило неверное - предполагалось, что ifrename -u будет вызываться не через PROGRAM, а через IMPORT.  Для программ, вызываемых через PROGRAM, udevd сохраняет вывод для использования в последующих подстановках "%c"; поскольку "%c" в данном правиле нет, вывод ifrename -u просто теряется.  Формат вывода ifrename -u разработан именно для использования в IMPORT:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/HOTPLUG-UDEV.txt
Потеря вывода приводит к тому, что udevd не получает информации о новом имени интерфейса, в результате старое (уже неверное) имя интерфейса сохраняется в базе udev и передаётся в hald.

Во-вторых, даже замена PROGRAM на IMPORT и добавление блокировок в ifrename не устраняет race при переименовании нескольких интерфейсов - блокировка просто уменьшает вероятность проявления проблемы.  Надёжная работа правила с IMPORT="/sbin/ifrename -u -i %k" возможна только при отсутствии в этом правиле опции -t.  При наличии опции -t ifrename переименовывает не только интерфейс, указанный в командной строке, но и интерфейс, занимающий имя, которое должно быть назначено обрабатываемому; если событие для этого мешающего интерфейса в этот момент обрабатывается udevd (или находится в очереди), оно будет обработано неверно (скорее всего, вообще не будет обработано, поскольку при обработке старого имени второго интерфейса ifrename обнаружит под этим именем уже переименованный первый интерфейс, для которого больше ничего делать не нужно).

Корректное с точки зрения udev правило должно выглядеть так:

SUBSYSTEM=="net", ACTION=="add", PROGRAM="/sbin/ifrename -D -i %k", NAME="%c"

(или NAME:="%c", если результат этого переименования нужно объявить окончательным, чтобы последующие правила на него не влияли).  В этом случае ifrename только определяет имя, которое должно быть назначено интерфейсу, и сообщает его процессу udevd, а само переименование выполняется udevd, причём без промежуточного изменения имён для других интерфейсов (благодаря чему оно не может помешать параллельной обработке переименования других интерфейсов, если только им не назначены имена вида *_rename - такие имена использовать нельзя).

Правда, появляется другое ограничение - правила udevd для переименования интерфейсов (не обязательно только это правило - могут быть другие правила, переустанавливающие NAME) должны обязательно устанавливать несовпадающие имена для всех интерфейсов; если для какого-то интерфейса нет правила, и назначенное ему по умолчанию имя мешает какому-то другому интерфейсу, оба интерфейса не будут переименованы.  На этот случай можно добавить дополнительную проверку: если при вызове ifrename -D -i %k в iftab не найдено подходящее имя для интерфейса, и при этом текущее имя интерфейса присутствует в iftab в качестве назначенного для одного из интерфейсов, переименовать интерфейс, сохранив базовое имя и выбрав любой не занятый в данный момент номер (причём номер не должен быть занят как в ядре, так и в iftab, так что просто переименование в eth%d не годится).  Также нельзя использовать в iftab имена с '*' в конце (разве что вынести их обработку на второй шаг).

Сергей, т.е. - коротко говоря:
идея привязывать eth0 и eth1 к мак-адресам посредством вызова ifrename из udev - неверна в корне, и проблемы будут вылезать в любом случае. Возможен только один вид использования ifrename - это смена имени интерфейса на уникальное, никому не принадлежащее.

Т.е. - возвращаемся к тому, что немешало-бы научить alterator-network менять имена для интерфейсов.

(В ответ на комментарий №16)
> Это правило неверное - предполагалось, что ifrename -u будет вызываться не
> через PROGRAM, а через IMPORT. 

Кстати, родное правило в wireless-tools выглядит так:

SUBSYSTEM=="net", ACTION=="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"

Нет, race недостаточно выиграть, race надо исправить.

(В ответ на комментарий №19)
> Нет, race недостаточно выиграть, race надо исправить.

Зачем ты выложил этот пакет с этим неправильным патчем ?

(In reply to comment #20)
> (В ответ на комментарий №19)
> > Нет, race недостаточно выиграть, race надо исправить.
> 
> Зачем ты выложил этот пакет с этим неправильным патчем ?

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

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

Чудом, да.. кто-нить сможет написать testcase для ifrename ? ;)

(In reply to comment #3)
> переименовывай во что нибудь отличное от ethX.
> других бесграбельных вариантов нет
Этот тоже грабельный -- в обсуждениях проблемы упоминали разный софт (открытый и закрытый), закладывающийся именно на ethX.

Софт, закладывающийся на eth* умрёт в любом случае - есть же ещё br0, wlan0, tap0 и т.д.

(В ответ на комментарий №7)
> Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать
> эти проблемы.
> 
> Assign => george@

Без меня меня женили. Каким образом я угодил в майнтейнеры этого пакета. Я один раз исправлял trivial (как казалось) баг в 4.1, добавил takeover. Без takeover наши дистрибутивы прямо из коробки работали с вероятностью 50% неправильно. Фиксить надо было, как обычно, "вчера". А исправление в 4.1 невозможно без исправления в Сизифе.

Вот и помогай после этого людям.

(In reply to comment #25)
> > Внезапно выяснил, что мантейнер пакета не legion, а george.
> Без меня меня женили. [...] Вот и помогай после этого людям.
Мужики, не кипятитесь.  Если бы это была единственная проблема с обязательными ACL и автоназначением кого попало, всё было бы ещё хорошо.

Насколько мне не нравится вседозволенность в виде @nobody by default -- всё-таки за неимением _адекватного_ механизма это меньшая плата за хорошие отношения.

Протестировал по просьбе Legion'а wireless-tools отсуда:
http://git.altlinux.org/people/legion/packages/wireless-tools.git?p=wireless-tools.git;a=tree;h=refs/heads/19313-try-1;hb=19313-try-1

У меня работают. Патча с блокировками там нет, интерфейсы переименовываются и так и эдак (20 перезагрузок).

> У меня работают. Патча с блокировками там нет, интерфейсы переименовываются и
> так и эдак (20 перезагрузок).
А если так, то что нам мешает получить его в Сизифе?

Так или иначе, проблема продолжает наблюдаться.
Например, сегодня, после установки office-server на ham1, после установки на нём наблюдались интерфейсы eth0, breth0 (сконфигурированный и работающий) и eth2 (несконфигурированный и неработающий). При наличии конфигурации для eth1/breth1. Средств исправить это через web интерфейс я не знаю.

wireless-tools-29-alt5 -> sisyphus:

* Thu May 28 2009 Dmitry V. Levin <ldv@altlinux> 29-alt5

- Added udev-ifrename helper, updated udev rule
  (by Alexey Gladkov; closes: #19313).
- ifrename: Removed no longer needed configuration file locking
  introduced in previous build.

(В ответ на комментарий №30)
> - Added udev-ifrename helper, updated udev rule
>   (by Alexey Gladkov; closes: #19313).

Вот только это не полное решение проблемы.

(In reply to comment #31)
> (В ответ на комментарий №30)
> > - Added udev-ifrename helper, updated udev rule
> >   (by Alexey Gladkov; closes: #19313).
> 
> Вот только это не полное решение проблемы.

Зато оно ближе к полному решению.

> Зато оно ближе к полному решению.

Я рад, что новых мантейнеров устраивает это временное решение.

Настоящее же решение может быть совсем не в ifrename, а в udev. Как вариант:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/rule_generator/write_net_rules;h=cb346757cc40050e034dada01224f4fc0790629b;hb=a29b30b4115db16035998c551117685d8152a496

Теперь breth1 превратился в неработающий breth1_rename

(In reply to comment #34)
> Теперь breth1 превратился в неработающий breth1_rename

Зачем в /etc/iftab указан breth1?  Нечего ему там делать!

> > Теперь breth1 превратился в неработающий breth1_rename
> Зачем в /etc/iftab указан breth1?  Нечего ему там делать!
А его там нет. Только eth0 и eth1

Ну и по прежнему не работает..

(In reply to comment #36)
> > > Теперь breth1 превратился в неработающий breth1_rename
> > Зачем в /etc/iftab указан breth1?  Нечего ему там делать!
> А его там нет. Только eth0 и eth1
> 
> Ну и по прежнему не работает..

Оно, очевидно, пытается переименовать breth1 в eth1, поскольку у них одинаковый mac, а eth1 внесён в /etc/iftab.

Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы наверняка отличить eth1 и от eth0, и от breth1?

SYSFS{type}
у физических интерфейсов он равен 1

(In reply to comment #37)
> Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы
> наверняка отличить eth1 и от eth0, и от breth1?

В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2 mac на bus.

не надо хаков. запись для физического интерфейса должна выглядеть следующим образом:
ethX SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1

(In reply to comment #40)
> не надо хаков. запись для физического интерфейса должна выглядеть следующим
> образом:
> ethX SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1

Так тоже не работает:

[root@host ~]# cat /etc/iftab 
eth0	SYSFS{address} 00:1a:64:a3:93:9c SYSFS{type} 1
eth1	SYSFS{address} 00:08:c7:8a:23:69 SYSFS{type} 1
[root@host ~]# ifrename -D -i breth0
Dry-run : Would rename breth0 to eth0.
eth0

ах ты блин. у бриджа type тоже 1
можно привязаться еще жестче, допустим по SYSFS{device}. см. man iftab

Да, дописывание "SYSFS{device} *" в iftab помогает отличить физические интерфейсы от bridge (причём, похоже, сейчас это работает независимо от CONFIG_SYSFS_DEPRECATED, несмотря на описание в man iftab). Возможно, не будет работать с какими-то особо кривыми драйверами, не выставляющими ссылку на физическое устройство.

installer-feature-eth-by-mac-stage3-0.4-alt1 -> sisyphus:

* Mon Jun 01 2009 Dmitry V. Levin <ldv@altlinux> 0.4-alt1

- Changed iftab format (closes: #19313).
- Switched to stage3.

(In reply to comment #39)
> В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2
> mac на bus.
Дима, тебе следует более внимательно читать рассылки и багзиллу. :)

Это уже обсуждалось (кажется, с asy@/vvk@); решили, что породит больше проблем: MAC более постоянен и меняется скорее со сменой карты, а вот порядок сканирования шин(ы) может плавать с ядром, его параметрами и IIRC версией BIOS.  Ну и переставив карточку в соседний слот, получаем отъезд привязки.

- Added udev-ifrename helper, updated udev rule
  (by Alexey Gladkov; closes: #19313).

в результате на 3-х машинах остался без сети
# /lib/ifrename/udev-ifrename eth0 
udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported
eth0

$ cat /etc/iftab 
# 82566MM Gigabit Network Connection
ether	mac 00:1D:72:82:50:03

# PRO/Wireless 4965 AG or AGN Network Connection
wifi	SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1

(In reply to comment #46)
> # /lib/ifrename/udev-ifrename eth0 
> udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported
> eth0

Значит, в скрипте udev-ifrename есть баги.

(В ответ на комментарий №47)
> (In reply to comment #46)
> > # /lib/ifrename/udev-ifrename eth0 
> > udev-ifrename: /etc/iftab line 3: : interface name patterns are not supported
> > eth0
> 
> Значит, в скрипте udev-ifrename есть баги.


Или, как пишет vsu@ : "Возможно, не будет
работать с какими-то особо кривыми драйверами, не выставляющими ссылку на
физическое устройство."

wireless-tools-29-alt6 -> sisyphus:

* Wed Jun 03 2009 Dmitry V. Levin <ldv@altlinux> 29-alt6

- udev-ifrename: Fixed comments handling (closes: #19313).