Bug 19313

Summary: Не срабатывает правило для udev
Product: Sisyphus Reporter: Anton Farygin <rider>
Component: ifrenameAssignee: placeholder <placeholder>
Status: CLOSED FIXED QA Contact: qa-sisyphus
Severity: critical    
Priority: P2 CC: aen, boyarsh, cas, glebfm, inger, ldv, mike, placeholder, rider, shrek, silicium, vitty, vsu, vvk
Version: unstable   
Hardware: all   
OS: Linux   
Attachments:
Description Flags
ifrename-alt-lockfile.patch none

Description Anton Farygin 2009-03-24 18:03:01 MSK
$ cat /etc/iftab 
eth0    mac 00:07:e9:0a:46:72
eth1    mac 00:0e:a6:5c:01:a0

После загрузки имеем eth1 и eth2
Comment 1 Anton Farygin 2009-03-24 18:17:03 MSK
Обновление версии ifrename не помогает.

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

Валера, а udev тут может как-то зафиксить этот вопрос ?
запускать ifrename только тогда, когда поток сетевых интерфейсов иссякнет ?
Comment 2 Alexey Gladkov 2009-03-24 18:21:55 MSK
Кажется такое невозможно.
Comment 3 Valery Inozemtsev 2009-03-24 21:32:09 MSK
переименовывай во что нибудь отличное от ethX. других бесграбельных вариантов нет
Comment 4 Anton Farygin 2009-03-25 09:37:49 MSK
Это к Стасу в alterator-network.

Впрочем, /etc/net/iftab сейчас тоже сломан, но там уже есть работающий патч:
https://bugzilla.altlinux.org/show_bug.cgi?id=11786
Comment 5 Anton Farygin 2009-03-25 10:28:23 MSK
Получил лог (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 ни в коем случае не должен трогать интерфейсы, для которых выполняется переименование... впрочем, видимо, это будет полезно и в других случаях.
Comment 6 Alexey Gladkov 2009-03-25 10:41:47 MSK
(В ответ на комментарий №5)
> Ну и что произошло, на русском:
> - пришло уведомление о том, что появился интерфейс eth1, udev вызвает ifrename,
> который, пытаясь поменять eth1 на eth0 обнаруживает наличие eth0, меняет eth1
> на eth2 (%d - это просто следующий свободный номер в ядре), и пытается eth0
> переименовать в eth1.

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

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

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

Из того что ты нашёл следует, что эта проблема не зависит от #14837. Это рейс  ifrename.
Comment 7 Alexey Gladkov 2009-03-25 10:51:56 MSK
Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать эти проблемы.

Assign => george@
Comment 8 Anton Farygin 2009-03-25 10:52:08 MSK
Судя по коду в ядре - в качестве блокировки интерфейса от смены имени - можно говорить ему IFF_UP (т.е. - выставлять флаг в UP).

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

И да, эта проблема - race в связке udev/ядра/ifrename. Про это было сразу понятно.
Comment 9 Anton Farygin 2009-03-25 10:54:10 MSK
Добавлю, что проблема воспроизводится на 5.0, а наши средства настройки активно используют /etc/iftab для привязки интерфейсов к мак-адресам. Соответственно, со всеми вытекающими последствиями в дистрибутивах.
Comment 10 Alexey Gladkov 2009-03-25 11:02:26 MSK
Антон, не меняй пожалуйста атрибуты бага без комментариев. Я больше не мантейнер этого пакета.

$ 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@
Comment 11 Anton Farygin 2009-03-25 11:05:57 MSK
гм. я ничего специально не менял.
Comment 12 Alexey Gladkov 2009-03-25 13:57:54 MSK
(В ответ на комментарий №11)
> гм. я ничего специально не менял.

Я знаю.
Comment 13 Alexey Gladkov 2009-03-25 14:00:54 MSK
Created attachment 3394 [details]
ifrename-alt-lockfile.patch

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

Спасибо, собрал 29-alt4 с этим патчем.
Comment 15 Anton Farygin 2009-03-27 09:33:56 MSK
Спасибо, всё работает отлично!
Comment 16 Sergey Vlasov 2009-03-27 15:28:35 MSK
На самом деле то, что сейчас сделано в пакете 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 имена с '*' в конце (разве что вынести их обработку на второй шаг).
Comment 17 Anton Farygin 2009-03-27 15:47:56 MSK
Сергей, т.е. - коротко говоря:
идея привязывать eth0 и eth1 к мак-адресам посредством вызова ifrename из udev - неверна в корне, и проблемы будут вылезать в любом случае. Возможен только один вид использования ifrename - это смена имени интерфейса на уникальное, никому не принадлежащее.

Т.е. - возвращаемся к тому, что немешало-бы научить alterator-network менять имена для интерфейсов.
Comment 18 Alexey Gladkov 2009-03-27 15:57:48 MSK
(В ответ на комментарий №16)
> Это правило неверное - предполагалось, что ifrename -u будет вызываться не
> через PROGRAM, а через IMPORT. 

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

SUBSYSTEM=="net", ACTION=="add", IMPORT="/sbin/ifrename -u -i %k", NAME:="%k"
Comment 19 Dmitry V. Levin 2009-03-29 04:17:58 MSD
Нет, race недостаточно выиграть, race надо исправить.
Comment 20 Alexey Gladkov 2009-03-29 17:52:47 MSD
(В ответ на комментарий №19)
> Нет, race недостаточно выиграть, race надо исправить.

Зачем ты выложил этот пакет с этим неправильным патчем ?
Comment 21 Dmitry V. Levin 2009-03-29 19:56:49 MSD
(In reply to comment #20)
> (В ответ на комментарий №19)
> > Нет, race недостаточно выиграть, race надо исправить.
> 
> Зачем ты выложил этот пакет с этим неправильным патчем ?

Я не считаю выложенный патч неправильным, я считаю его недостаточным.
Comment 22 Anton Farygin 2009-03-29 19:58:36 MSD
ну, если уж исходить с точки зрения пользователя - то по крайней мере у меня этот пакет с недостаточным патчем заработал.

Чудом, да.. кто-нить сможет написать testcase для ifrename ? ;)
Comment 23 Michael Shigorin 2009-03-29 20:11:57 MSD
(In reply to comment #3)
> переименовывай во что нибудь отличное от ethX.
> других бесграбельных вариантов нет
Этот тоже грабельный -- в обсуждениях проблемы упоминали разный софт (открытый и закрытый), закладывающийся именно на ethX.
Comment 24 Anton Farygin 2009-03-29 20:15:00 MSD
Софт, закладывающийся на eth* умрёт в любом случае - есть же ещё br0, wlan0, tap0 и т.д.
Comment 25 Fr. Br. George 2009-03-31 00:59:35 MSD
(В ответ на комментарий №7)
> Внезапно выяснил, что мантейнер пакета не legion, а george. Тогда ему и решать
> эти проблемы.
> 
> Assign => george@

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

Вот и помогай после этого людям.
Comment 26 Michael Shigorin 2009-04-01 23:07:47 MSD
(In reply to comment #25)
> > Внезапно выяснил, что мантейнер пакета не legion, а george.
> Без меня меня женили. [...] Вот и помогай после этого людям.
Мужики, не кипятитесь.  Если бы это была единственная проблема с обязательными ACL и автоназначением кого попало, всё было бы ещё хорошо.

Насколько мне не нравится вседозволенность в виде @nobody by default -- всё-таки за неимением _адекватного_ механизма это меньшая плата за хорошие отношения.
Comment 27 Anton Farygin 2009-04-08 10:05:52 MSD
Протестировал по просьбе 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 перезагрузок).
Comment 28 Anton V. Boyarshinov 2009-04-09 18:01:56 MSD
> У меня работают. Патча с блокировками там нет, интерфейсы переименовываются и
> так и эдак (20 перезагрузок).
А если так, то что нам мешает получить его в Сизифе?
Comment 29 Anton V. Boyarshinov 2009-05-27 13:43:20 MSD
Так или иначе, проблема продолжает наблюдаться.
Например, сегодня, после установки office-server на ham1, после установки на нём наблюдались интерфейсы eth0, breth0 (сконфигурированный и работающий) и eth2 (несконфигурированный и неработающий). При наличии конфигурации для eth1/breth1. Средств исправить это через web интерфейс я не знаю.
Comment 30 Repository Robot 2009-05-28 15:04:24 MSD
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.
Comment 31 Alexey Gladkov 2009-05-28 15:11:32 MSD
(В ответ на комментарий №30)
> - Added udev-ifrename helper, updated udev rule
>   (by Alexey Gladkov; closes: #19313).

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

Зато оно ближе к полному решению.
Comment 33 Alexey Gladkov 2009-05-28 17:15:48 MSD
> Зато оно ближе к полному решению.

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

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

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/rule_generator/write_net_rules;h=cb346757cc40050e034dada01224f4fc0790629b;hb=a29b30b4115db16035998c551117685d8152a496
Comment 34 Anton V. Boyarshinov 2009-05-29 12:15:35 MSD
Теперь breth1 превратился в неработающий breth1_rename
Comment 35 Dmitry V. Levin 2009-05-30 02:15:31 MSD
(In reply to comment #34)
> Теперь breth1 превратился в неработающий breth1_rename

Зачем в /etc/iftab указан breth1?  Нечего ему там делать!
Comment 36 Anton V. Boyarshinov 2009-06-01 14:28:26 MSD
> > Теперь breth1 превратился в неработающий breth1_rename
> Зачем в /etc/iftab указан breth1?  Нечего ему там делать!
А его там нет. Только eth0 и eth1

Ну и по прежнему не работает..
Comment 37 Dmitry V. Levin 2009-06-01 14:41:07 MSD
(In reply to comment #36)
> > > Теперь breth1 превратился в неработающий breth1_rename
> > Зачем в /etc/iftab указан breth1?  Нечего ему там делать!
> А его там нет. Только eth0 и eth1
> 
> Ну и по прежнему не работает..

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

Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы наверняка отличить eth1 и от eth0, и от breth1?
Comment 38 Valery Inozemtsev 2009-06-01 14:49:44 MSD
SYSFS{type}
у физических интерфейсов он равен 1
Comment 39 Dmitry V. Levin 2009-06-01 15:03:08 MSD
(In reply to comment #37)
> Есть ли в iftab(5) какая-нибудь характеристика, по которой можно было бы
> наверняка отличить eth1 и от eth0, и от breth1?

В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2 mac на bus.
Comment 40 Valery Inozemtsev 2009-06-01 15:10:33 MSD
не надо хаков. запись для физического интерфейса должна выглядеть следующим образом:
ethX SYSFS{address} 00:1d:e0:b2:f0:5d SYSFS{type} 1
Comment 41 Dmitry V. Levin 2009-06-01 15:30:05 MSD
(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
Comment 42 Valery Inozemtsev 2009-06-01 15:42:27 MSD
ах ты блин. у бриджа type тоже 1
можно привязаться еще жестче, допустим по SYSFS{device}. см. man iftab
Comment 43 Sergey Vlasov 2009-06-01 16:03:15 MSD
Да, дописывание "SYSFS{device} *" в iftab помогает отличить физические интерфейсы от bridge (причём, похоже, сейчас это работает независимо от CONFIG_SYSFS_DEPRECATED, несмотря на описание в man iftab). Возможно, не будет работать с какими-то особо кривыми драйверами, не выставляющими ссылку на физическое устройство.
Comment 44 Repository Robot 2009-06-01 18:37:25 MSD
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.
Comment 45 Michael Shigorin 2009-06-02 00:55:44 MSD
(In reply to comment #39)
> В качестве быстрого хака могу заменить в installer-feature-eth-by-mac-stage2
> mac на bus.
Дима, тебе следует более внимательно читать рассылки и багзиллу. :)

Это уже обсуждалось (кажется, с asy@/vvk@); решили, что породит больше проблем: MAC более постоянен и меняется скорее со сменой карты, а вот порядок сканирования шин(ы) может плавать с ядром, его параметрами и IIRC версией BIOS.  Ну и переставив карточку в соседний слот, получаем отъезд привязки.
Comment 46 Valery Inozemtsev 2009-06-03 10:57:09 MSD
- 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
Comment 47 Dmitry V. Levin 2009-06-03 14:40:30 MSD
(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 есть баги.
Comment 48 AEN 2009-06-03 14:51:14 MSD
(В ответ на комментарий №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@ : "Возможно, не будет
работать с какими-то особо кривыми драйверами, не выставляющими ссылку на
физическое устройство."
Comment 49 Repository Robot 2009-06-03 18:54:57 MSD
wireless-tools-29-alt6 -> sisyphus:

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

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