ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Повисание на стадии populating /dev | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Denis V. Chernosov <dvc> |
| Component: | udev | Assignee: | 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 | ||
Забыл сказать, что такой же баг был на тех же машинах с установленным ASP 11.2. Правда лечить его аналогичным способом я не пробовал. Если руки дойдут - отпишусь... Сегодня еще раз выключали свет. Машина с ASP11.2 повисла на этом моменте, но после нажатия ctrl+alt+del перезагрузилась и всё пучком. А две машины с ALD4 и ALD4.0.2 повисали намертво на той же самой строчке. Экспериментальным путем выяснил, что помогает удаление какого-то или каких-то файлов из /var/run Что именно нужно удалять, пока не понял, видимо будем ждать следующего выключения света. Не хотел бы я такой сюрприз на сервере поиметь :( Пожалуйста, выясните, какой именно файл мешает - у меня это не воспроизводится. Кстати, никакого "бинарного файла с базой обнаруженных устройств" в /var нет (по крайней мере, udev такие файлы там не хранит). Кстати, на этих машинах база пользователей хранится в LDAP? Тогда, скорее всего, проблемы не в самом udev, а в nss_ldap. >Пожалуйста, выясните, какой именно файл мешает - у меня это не воспроизводится. Ну свет выключают у нас частенько... думаю, что в течение месяца-двух само воспроизведётся. Здесь просто получилось так, что сразу две машинки выпали в осадок и можно было сравнивать, удаление каких файлов влияет. Правда, это всё - время. А работа стоит. Поэтому удалял файлы пачками. >Кстати, никакого "бинарного файла с базой обнаруженных устройств" в /var нет >(по крайней мере, udev такие файлы там не хранит). Я и сам уже понял. Скорее всего это какой-то сокет или pid-файл. Или несколько файлов. > Кстати, на этих машинах база пользователей хранится в LDAP? Тогда, скорее > всего, проблемы не в самом udev, а в nss_ldap. Действительно в LDAP, но удивительно, что это начинает влиять на таком раннем этапе... Ему [udev] это для раздачи прав на устройство нужно что ли? И на какие файлы тады смотреть нужно? P.S. Не знаю, важно ли это, но когда вываливаешься в рутовую консоль после неудачной попытки запуска, то ps ax | grep udev выдает кучу (несколько десятков) процессов /sbin/udevd --daemon [или что-то в этом духе :), я не записал в точности]. В правилах udev (/etc/udev/rules.d/*) используются имена пользователей и групп, для преобразования которых в числовые идентификаторы используется NSS в glibc. Предполагается, что в /etc/nsswitch.conf на первом месте для passwd и group стоит files, а все пользователи и группы, упоминающиеся в правилах, присутствуют в локальных файлах - в этом случае при загрузке не должны происходить обращения к другим модулям NSS, кроме nss_files. Возможно, какие-то пакеты содержат ошибочные файлы в /etc/udev/rules.d, где указаны имена несуществующих пользователей или групп. (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@. Ага, только 0.5 не собирается... закинул пока 0.4.1-alt0.1 as is. Проблема повторилась на ALD 4.0.3 (20080207). Да, авторизация в LDAP, но лечится почему-то чисткой: /var/lock/subsys - это точно не файлы, начинающиеся с udev*, потому что их я удалил отдельным заходом. /var/run - помятуя о прошлых попытках, удалял исключительно файлы, не касаясь папок. Точнее зафиксировать опять не удалось, но это точно там. Причем, я больше грешу на pid-ы и/или сокеты, которые не удалились при нештатной перезагрузке. Типа udev находит pid или сокет и пытается по нему провзаимодействовать с каким-то другим приложением. А его и нет в наличии. Вот и вываливается всё в рутовую консоль. 2 inger: возможно, в зависимости alterator-auth (или кто умеет настраиваться на ldap) стоит включить nss-ldapd. 2 boyarsh: был положительный отзыв про nss-ldapd со стороны barabashka@, мож давай повешу отдельную багу на mkimage-profiles-desktop, чтоб не забыть его положить? Проблема действительно получается довольно неприятная. (In reply to comment #9) > 2 inger: возможно, в зависимости alterator-auth (или кто умеет настраиваться на > ldap) стоит включить nss-ldapd. Зависимости быть не должно, alterator-auth - общий модуль, что будет в системе - то и настроит. nss-ldapd он теоретически должен поддерживать ибо формат конфига там не поменялся. Круг поиска сужается до папки /var/run/console/ Похоже, причина проблем - вызов /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 были применены так же, как и при обычной обработке правил. (In reply to comment #12) > Если при неожиданной перезагрузке остался файл > /var/run/console/console.lock Мож его просто грохать или в это время /var может быть ещё r/o? Вообще где-то /var/run уже поутаскивали на tmpfs, кажется. >Вообще где-то /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 ... (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 просто некуда. (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. И как раз это оказывается фатальным... Есть ли какая-то динамика по решению этого бага? Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном поведении клиентских машин в нештатной ситуации. При наличии проблем с электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с бубном гарантированы. Есть ли какой-нибудь костыль для решения проблемы? (In reply to comment #17) > Есть ли какая-то динамика по решению этого бага? > Страшно внедрять авторизацию на LDAP в удаленных конторах, при таком неприятном > поведении клиентских машин в нештатной ситуации. При наличии проблем с > электричеством или не очень хорошо поддерживаемым железом, регулярные танцы с > бубном гарантированы. > Есть ли какой-нибудь костыль для решения проблемы? Объезд давно найден: либо ставить nss-ldapd, либо править /etc/nss-*.conf в сторону уменьшения timeout'ов до разумных пределов (30-60 секунд) и выставления bind_policy. Баг легко воспроизводим. Дергаем сетевой провод из машины, перезагружаем машину, на загрузке ловим баг. (In reply to comment #18) > Объезд давно найден: либо ставить nss-ldapd, либо править /etc/nss-*.conf в > сторону уменьшения timeout'ов до разумных пределов (30-60 секунд) и выставления > bind_policy. > nss-ldapd еще не ставил, хотя описание в Сизифе красивое :) таймауты в свежих версиях и так по 5 выставлены по умолчанию. А вот явное выставление: bind_policy soft - помогло. > Баг легко воспроизводим. > > Дергаем сетевой провод из машины, перезагружаем машину, на загрузке ловим баг. > Ну так я не пробовал. У меня было при нештатной перезагрузке. И сейчас устроил сразу краш-тест. Зашел под сетевым юзером нажал на резет. Полет нормальный. Зашел еще раз под сетевым юзером, выдернул кабель и нажал резет. Загрузка прошла нормально, но пользователь не логинится... хм... вставил кабель... не логинится... а если... service network restart и полет нормальный. Так что будем надеяться, что в новых сборках эта проблема будет из коробки решена. Спасибо за совет! (In reply to comment #19) > А вот явное выставление: > bind_policy soft - помогло. Это стоит повесить отдельной багой. > Так что будем надеяться, что в новых сборках эта проблема будет > из коробки решена. Не надо надеяться, багу надо вешать. У меня воспроизвелось (очень долгий 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 2 shrek: говорят (iv@ в devel@), что это воспроизводится на сизифе недельной давности. Валера, можно выяснить - на чём именно его колбасит и удалять это в стартовом скрипте второй строчкой ? wmaster давно не обрабатывается. /sbin/pam_console_apply давно не вызывается |
Вероятно, связано с нештатной перезагрузкой (выключали свет). Система начинает намертво виснуть при загрузке на сообщении populating /udev висит долго (минут десять, если не больше). Потом пытается вывалиться в однопользовательскую рутовую консоль, но авторизация и там не проходит (точнее проходит, но не каждый раз. И всё равно не помогает ничего сделать, потому что рутовый раздел доступен только для чтения и в /dev практически никаких устройств нет). Суть сообщений сводится к тому, что не получается нормально примонтировать рутовый раздел. РЕШЕНИЕ: Подключил диск к другой машине и почистил /tmp, /var/{tmp,run,lock,...} - ПРОБЛЕМЫ КАК НЕ БЫВАЛО!!! Отсюда вывод - проблемы возникают от того, что udev не очень корректно реагирует на ситуацию, когда имеется некоторый pid, socket и/или - какой-то другой временный файл, оставшийся неудаленным с прошлой загрузки. Возможно бъется бинарный файл с базой обнаруженных устройств. Похоже, что от железа он зависит только в том смысле, насколько вероятно неудаление/поломки критичного временного файла при проблемах с электроэнергией.