Bug 13656

Summary: Повисание на стадии populating /dev
Product: Sisyphus Reporter: Denis V. Chernosov <dvc>
Component: udevAssignee: Alexey Shabalin <shaba>
Status: CLOSED FIXED QA Contact: Q.A. 4.0 <qa-4.0>
Severity: normal    
Priority: P2 CC: arseny, barabashka, boyarsh, eostapets, gns, inger, iv, mike, rider, shaba, sr, wrar
Version: unstable   
Hardware: all   
OS: Linux   

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

populating /udev

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

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

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

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

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

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

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

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


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

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


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

 

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



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


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

Возможно, какие-то пакеты содержат ошибочные файлы в /etc/udev/rules.d, где
указаны имена несуществующих пользователей или групп.
Comment 6 Michael Shigorin 2007-12-27 21:21:56 MSK
(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 Michael Shigorin 2007-12-27 22:11:54 MSK
Ага, только 0.5 не собирается... закинул пока 0.4.1-alt0.1 as is.
Comment 8 Denis V. Chernosov 2008-02-20 09:38:32 MSK
Проблема повторилась на ALD 4.0.3 (20080207). Да, авторизация в LDAP, но лечится
почему-то чисткой:
/var/lock/subsys - это точно не файлы, начинающиеся с udev*, потому что их я
удалил отдельным заходом.
/var/run - помятуя о прошлых попытках, удалял исключительно файлы, не касаясь папок.

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

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

Comment 11 Denis V. Chernosov 2008-02-22 13:41:54 MSK
Круг поиска сужается до папки /var/run/console/
Comment 12 Sergey Vlasov 2008-03-11 18:22:32 MSK
Похоже, причина проблем - вызов /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 Michael Shigorin 2008-03-11 21:54:27 MSK
(In reply to comment #12)
> Если при неожиданной перезагрузке остался файл
> /var/run/console/console.lock
Мож его просто грохать или в это время /var может быть ещё r/o?

Вообще где-то /var/run уже поутаскивали на tmpfs, кажется.
Comment 14 Denis V. Chernosov 2008-03-24 11:23:40 MSK
>Вообще где-то /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 Sergey Vlasov 2008-03-24 14:36:50 MSK
(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 Denis V. Chernosov 2008-03-28 11:51:39 MSK
(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 Denis V. Chernosov 2008-04-28 15:51:43 MSD
Есть ли какая-то динамика по решению этого бага?
Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном
поведении клиентских машин в нештатной ситуации. При наличии проблем с
электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с
бубном гарантированы.
Есть ли какой-нибудь костыль для решения проблемы?
Comment 18 barabashka 2008-04-28 18:47:25 MSD
(In reply to comment #17)
> Есть ли какая-то динамика по решению этого бага?
> Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном
> поведении клиентских машин в нештатной ситуации. При наличии проблем с
> электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с
> бубном гарантированы.
> Есть ли какой-нибудь костыль для решения проблемы?

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

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

Дергаем сетевой провод из машины, перезагружаем машину, на загрузке ловим баг.
Comment 19 Denis V. Chernosov 2008-04-29 10:19:53 MSD
(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 Michael Shigorin 2008-05-06 21:50:04 MSD
(In reply to comment #19)
> А вот явное выставление:
> bind_policy soft - помогло.
Это стоит повесить отдельной багой.

> Так что будем надеяться, что в новых сборках эта проблема будет
> из коробки решена. 
Не надо надеяться, багу надо вешать.
Comment 21 Ivan A. Melnikov 2009-01-17 15:09:17 MSK
У меня воспроизвелось (очень долгий 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 Michael Shigorin 2009-01-17 17:34:39 MSK
2 shrek: говорят (iv@ в devel@), что это воспроизводится на сизифе недельной давности.
Comment 23 Anton Farygin 2009-01-17 22:20:53 MSK
Валера, можно выяснить - на чём именно его колбасит и удалять это в стартовом скрипте второй строчкой ?
Comment 24 Valery Inozemtsev 2009-05-17 13:31:19 MSD
wmaster давно не обрабатывается. /sbin/pam_console_apply давно не вызывается