Bug 13656 - Повисание на стадии populating /dev
: Повисание на стадии populating /dev
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/udev)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2007-12-11 08:40 by
Modified: 2009-05-17 13:31 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-12-11 08:40:21
Вероятно, связано с нештатной перезагрузкой (выключали свет).
Система начинает намертво виснуть при загрузке на сообщении

populating /udev

висит долго (минут десять, если не больше). Потом пытается вывалиться в
однопользовательскую рутовую консоль, но авторизация и там не проходит (точнее
проходит, но не каждый раз. И всё равно не помогает ничего сделать, потому что
рутовый раздел доступен только для чтения и в /dev практически никаких
устройств
нет). Суть сообщений сводится к тому, что не получается нормально
примонтировать
рутовый раздел.

РЕШЕНИЕ:
Подключил диск к другой машине и почистил /tmp, /var/{tmp,run,lock,...}  -
ПРОБЛЕМЫ КАК НЕ БЫВАЛО!!!

Отсюда вывод  - проблемы возникают от того, что udev не очень корректно
реагирует на ситуацию, когда имеется некоторый pid, socket и/или - какой-то
другой временный файл, оставшийся неудаленным с прошлой загрузки.  Возможно
бъется бинарный файл с базой обнаруженных устройств.

Похоже, что от железа он зависит только в том смысле, насколько вероятно
неудаление/поломки критичного временного файла при проблемах с электроэнергией.
------- Comment #1 From 2007-12-11 08:45:57 -------
Забыл сказать, что такой же баг был на тех же машинах с установленным ASP 11.2.
Правда лечить его аналогичным способом я не пробовал. Если руки дойдут -
отпишусь...
------- Comment #2 From 2007-12-25 15:59:54 -------
Сегодня еще раз выключали свет. Машина с ASP11.2 повисла на этом моменте, но
после нажатия ctrl+alt+del перезагрузилась и всё пучком.

А две машины с ALD4 и ALD4.0.2 повисали намертво на той же самой строчке.
Экспериментальным путем выяснил, что помогает удаление какого-то или каких-то
файлов из /var/run

Что именно нужно удалять, пока не понял, видимо будем ждать следующего
выключения света. Не хотел бы я такой сюрприз на сервере поиметь :(
------- Comment #3 From 2007-12-25 17:29:31 -------
Пожалуйста, выясните, какой именно файл мешает - у меня это не воспроизводится.

Кстати, никакого "бинарного файла с базой обнаруженных устройств" в /var нет
(по
крайней мере, udev такие файлы там не хранит).

Кстати, на этих машинах база пользователей хранится в LDAP?  Тогда, скорее
всего, проблемы не в самом udev, а в nss_ldap.
------- Comment #4 From 2007-12-26 08:58:56 -------
>Пожалуйста, выясните, какой именно файл мешает - у меня это не воспроизводится.


Ну свет выключают у нас частенько... думаю, что в течение месяца-двух само
воспроизведётся. Здесь просто получилось так, что сразу две машинки выпали в
осадок и можно было сравнивать, удаление каких файлов влияет. Правда, это всё -
время. А работа стоит. Поэтому удалял файлы пачками.


>Кстати, никакого "бинарного файла с базой обнаруженных устройств" в /var нет
>(по крайней мере, udev такие файлы там не хранит).


Я и сам уже понял. Скорее всего это какой-то сокет или pid-файл. Или несколько
файлов.



>    Кстати, на этих машинах база пользователей хранится в LDAP?  Тогда, скорее
>    всего, проблемы не в самом udev, а в nss_ldap.



Действительно в LDAP, но удивительно, что это начинает влиять на таком раннем
этапе... Ему [udev] это для раздачи прав на устройство нужно что ли? И на какие
файлы тады смотреть нужно? 


P.S. Не знаю, важно ли это, но когда вываливаешься в рутовую консоль после
неудачной попытки запуска, то ps ax | grep udev выдает кучу (несколько
десятков)
процессов /sbin/udevd --daemon [или что-то в этом духе :), я не записал в
точности].
------- Comment #5 From 2007-12-26 13:51:39 -------
В правилах udev (/etc/udev/rules.d/*) используются имена пользователей и групп,
для преобразования которых в числовые идентификаторы используется NSS в glibc.
Предполагается, что в /etc/nsswitch.conf на первом месте для passwd и group
стоит files, а все пользователи и группы, упоминающиеся в правилах,
присутствуют
в локальных файлах - в этом случае при загрузке не должны происходить обращения
к другим модулям NSS, кроме nss_files.

Возможно, какие-то пакеты содержат ошибочные файлы в /etc/udev/rules.d, где
указаны имена несуществующих пользователей или групп.
------- Comment #6 From 2007-12-27 21:21:56 -------
(In reply to comment #4)
> Действительно в LDAP

https://bugzilla.altlinux.org/show_bug.cgi?id=11420
https://bugzilla.altlinux.org/show_bug.cgi?id=11421
http://lists.altlinux.ru/pipermail/devel/2007-November/065669.html

Аккурат сегодня вышел 0.5.0 -- наверное, повод наконец закинуть в сизиф и бранч.
 Занимаюсь сборкой, исходя из пакета gns@.
------- Comment #7 From 2007-12-27 22:11:54 -------
Ага, только 0.5 не собирается... закинул пока 0.4.1-alt0.1 as is.
------- Comment #8 From 2008-02-20 09:38:32 -------
Проблема повторилась на ALD 4.0.3 (20080207). Да, авторизация в LDAP, но
лечится
почему-то чисткой:
/var/lock/subsys - это точно не файлы, начинающиеся с udev*, потому что их я
удалил отдельным заходом.
/var/run - помятуя о прошлых попытках, удалял исключительно файлы, не касаясь
папок.

Точнее зафиксировать опять не удалось, но это точно там. Причем, я больше грешу
на  pid-ы и/или сокеты, которые не удалились при нештатной перезагрузке. Типа
udev находит pid или сокет и пытается по нему провзаимодействовать с каким-то
другим приложением. А его и нет в наличии. Вот и вываливается всё в рутовую
консоль.
------- Comment #9 From 2008-02-20 13:31:27 -------
2 inger: возможно, в зависимости alterator-auth (или кто умеет настраиваться на
ldap) стоит включить nss-ldapd.

2 boyarsh: был положительный отзыв про nss-ldapd со стороны barabashka@, мож
давай повешу отдельную багу на mkimage-profiles-desktop, чтоб не забыть его
положить?  Проблема действительно получается довольно неприятная.
------- Comment #10 From 2008-02-21 12:47:21 -------
(In reply to comment #9)
> 2 inger: возможно, в зависимости alterator-auth (или кто умеет настраиваться на
> ldap) стоит включить nss-ldapd.
Зависимости быть не должно, alterator-auth - общий модуль, что будет в системе -
то и настроит.
nss-ldapd он теоретически должен поддерживать ибо формат конфига там не поменялся.

------- Comment #11 From 2008-02-22 13:41:54 -------
Круг поиска сужается до папки /var/run/console/
------- Comment #12 From 2008-03-11 18:22:32 -------
Похоже, причина проблем - вызов /sbin/pam_console_apply, выполняемый из
/etc/udev/rules.d/94-pam-console.rules и необходимый для правильной работы udev
с pam_console. Если при неожиданной перезагрузке остался файл
/var/run/console/console.lock, содержащий имя пользователя, которое отсутствует
в локальных файлах, pam_console_apply будет пытаться обратиться к другим
модулям
NSS - в данном случае к nss_ldap.

Можно попробовать, например, отключить вызов pam_console_apply на ранних
стадиях
загрузки системы; правда, потом придётся где-то добавить вызов
pam_console_apply, чтобы права из настроек pam_console были применены так же,
как и при обычной обработке правил.
------- Comment #13 From 2008-03-11 21:54:27 -------
(In reply to comment #12)
> Если при неожиданной перезагрузке остался файл
> /var/run/console/console.lock
Мож его просто грохать или в это время /var может быть ещё r/o?

Вообще где-то /var/run уже поутаскивали на tmpfs, кажется.
------- Comment #14 From 2008-03-24 11:23:40 -------
>Вообще где-то /var/run уже поутаскивали на tmpfs, кажется.
Мне кажется - это было бы самым изящным решением проблемы.

Погуглил чуть-чуть и нашел, например такое мнение:
http://klek07.ya.ru/replies.xml?item_no=228&ncrnd=3598

или здесь, например, чел конфиг цитирует:
http://forum.ubuntu.ru/index.php?action=profile;u=4006;sa=showPosts

rab@oper:~$ cat < /etc/mtab
...
varrun /var/run tmpfs rw,noexec,nosuid,nodev,mode=0755 0 0
varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode=1777 0 0
...
udev /dev tmpfs rw,mode=0755 0 0
devshm /dev/shm tmpfs rw 0 0
devpts /dev/pts devpts rw,gid=5,mode=620 0 0
lrm /lib/modules/2.6.17-10-386/volatile tmpfs rw 0 0
...
------- Comment #15 From 2008-03-24 14:36:50 -------
(In reply to comment #14)
> varrun /var/run tmpfs rw,noexec,nosuid,nodev,mode=0755 0 0
> varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode=1777 0 0

Проблема с таким решением в том, что в тот момент, когда проявляется баг (запуск
udevd из rc.sysinit даже до перемонтирования корня в rw), каталоги /var/run и
/var/lock могут вообще не существовать, если /var находится на отдельной ФС -
получается, что монтировать эти tmpfs просто некуда.
------- Comment #16 From 2008-03-28 11:51:39 -------
(In reply to comment #15)
> (In reply to comment #14)
> > varrun /var/run tmpfs rw,noexec,nosuid,nodev,mode=0755 0 0
> > varlock /var/lock tmpfs rw,noexec,nosuid,nodev,mode=1777 0 0
> 
> Проблема с таким решением в том, что в тот момент, когда проявляется баг (запуск
> udevd из rc.sysinit даже до перемонтирования корня в rw), каталоги /var/run и
> /var/lock могут вообще не существовать, если /var находится на отдельной ФС -
> получается, что монтировать эти tmpfs просто некуда.

Я конечно не спец, но именно в этот момент (запуск udevd из rc.sysinit) ничего
страшного я не наблюдал. Нет /var/{run,lock}, значит и анализировать нечего. 

Зато при попытке добавить вышеуказанные строки в /etc/fstab (кстати, они, как и
/{tmp,proc,dev}, могут стоять в этом файле и ДО монтирования / - почему-то это
не играет роли), выпадают другие глюки - многие программы не могут создать
промежуточные папки, как то /var/lock/subsys. И как раз это оказывается фатальным...
------- Comment #17 From 2008-04-28 15:51:43 -------
Есть ли какая-то динамика по решению этого бага?
Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном
поведении клиентских машин в нештатной ситуации. При наличии проблем с
электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с
бубном гарантированы.
Есть ли какой-нибудь костыль для решения проблемы?
------- Comment #18 From 2008-04-28 18:47:25 -------
(In reply to comment #17)
> Есть ли какая-то динамика по решению этого бага?
> Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном
> поведении клиентских машин в нештатной ситуации. При наличии проблем с
> электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с
> бубном гарантированы.
> Есть ли какой-нибудь костыль для решения проблемы?

Объезд давно найден: либо ставить nss-ldapd, либо  править /etc/nss-*.conf в
сторону уменьшения timeout'ов до разумных пределов (30-60 секунд) и выставления
bind_policy.

Баг легко воспроизводим.

Дергаем сетевой провод из машины, перезагружаем машину, на загрузке ловим баг.
------- Comment #19 From 2008-04-29 10:19:53 -------
(In reply to comment #18)
> Объезд давно найден: либо ставить nss-ldapd, либо  править /etc/nss-*.conf в
> сторону уменьшения timeout'ов до разумных пределов (30-60 секунд) и выставления
> bind_policy.
> 

nss-ldapd еще не ставил, хотя описание в Сизифе красивое :)
таймауты в свежих версиях и так по 5 выставлены по умолчанию. 
А вот явное выставление:
bind_policy soft - помогло.

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

Ну так я не пробовал. У меня было при нештатной перезагрузке. И сейчас устроил
сразу краш-тест. Зашел под сетевым юзером нажал на резет. Полет нормальный.
Зашел еще раз под сетевым юзером, выдернул кабель и нажал резет. Загрузка прошла
нормально, но пользователь не логинится... хм... вставил кабель... не
логинится... а если... service network restart и полет нормальный. 

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

Спасибо за совет!
------- Comment #20 From 2008-05-06 21:50:04 -------
(In reply to comment #19)
> А вот явное выставление:
> bind_policy soft - помогло.
Это стоит повесить отдельной багой.

> Так что будем надеяться, что в новых сборках эта проблема будет
> из коробки решена. 
Не надо надеяться, багу надо вешать.
------- Comment #21 From 2009-01-17 15:09:17 -------
У меня воспроизвелось (очень долгий Populating /dev) после kernel panic.

Небольшое расследование показало, что проблема решается удалением
/var/lock/subsys/network. Подозреваю, что в моем случае виноват neg-agent.c
(или net.agent). В пользу этой гипотезы говорит и то, что если дождаться
таймаута udev, появляется сообщение, указывающее в частности, что в очереди
/sys/<что-то>/wmaster0 (к сожалению точный текст потерян).

Система -- Cизиф от 12.01,
$ rpm -qa udev
udev-136-alt1
------- Comment #22 From 2009-01-17 17:34:39 -------
2 shrek: говорят (iv@ в devel@), что это воспроизводится на сизифе недельной
давности.
------- Comment #23 From 2009-01-17 22:20:53 -------
Валера, можно выяснить - на чём именно его колбасит и удалять это в стартовом
скрипте второй строчкой ?
------- Comment #24 From 2009-05-17 13:31:19 -------
wmaster давно не обрабатывается. /sbin/pam_console_apply давно не вызывается