Created attachment 3466 [details] xsession-errors:0 Была обнаружена неработоспособность kde4 в ситуации, когда инофрмация о пользователе доступна только через ldap. То есть если для ldap пользователя есть локальный пользователь с соответствующим id, то работает, для "честого" же ldap пользователя, для которого нет локальной записи с таким id виснет на старте. Консольный логин работает, id отдаёт релевантную инормацию
А dbus-launch запущен? Это свежепоставленная система или уже наставлено разных пакетов?
dbus-launch запущен, но даже dbus-monitor --system ругается: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. От "нормального" пользователя стартует. По просьбе Антона перевешиваю на dbus.
https://bugzilla.redhat.com/show_bug.cgi?id=239355
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 Такое впечатление, что ни в Федоре ни в Убунту никто так и не заглянул собственно в код dbus.. А нам придётся...
так и не должен dbus знать о пользователях из ldap, т.к. стартует еще до сети
(В ответ на комментарий №5) > так и не должен dbus знать о пользователях из ldap, т.к. стартует еще до сети А он что -- вычитывает всех пользователей при старте и никого, кто появляется позже, за людей не считает? По идее ему следует проверять существование и полномочия пользователя при обращении..
по идее да. но на сколько я вижу все поднимают dbus выше ldap
(В ответ на комментарий №7) > по идее да. но на сколько я вижу все поднимают dbus выше ldap Тогда нельзя сеть NM-ом поднимать.. Ну и, опять же, тогда при добавлении ldap-овского ползователя dbus на всех машинах перезапускать... Увы, это выглядит блокером для всей пятой платформы :( Видимо придётся разбираться и сурово патчить. Хотя прекрасно понимаю, что хотелось бы обойтись без этого..
(В ответ на комментарий №4) > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 > Здесь описано решение, разве нет?
(В ответ на комментарий №9) > (В ответ на комментарий №4) > > https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/139098 > > > Здесь описано решение, разве нет? Прочитал #8 и понял, да.
Похожий баг: https://bugzilla.redhat.com/show_bug.cgi?id=182464
(В ответ на комментарий №8) > (В ответ на комментарий №7) > > по идее да. но на сколько я вижу все поднимают dbus выше ldap > > Тогда нельзя сеть NM-ом поднимать.. Ну и, опять же, тогда при добавлении > ldap-овского ползователя dbus на всех машинах перезапускать... > http://www.openldap.org/lists/openldap-technical/200803/msg00021.html Здесь опускают ldap ниже всех.
Похоже на это: https://bugzilla.redhat.com/show_bug.cgi?id=186527 Comment #54 From Andrew McNabb 2008-12-01 19:02:32 EDT ------- Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else is just a temporary workaround.
> Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else > is just a temporary workaround. Да, использование nss-ldapd решает проблему.
(In reply to comment #14) > > Until nss-ldapd replaces nss_ldap, this problem won't go away. Everything else > > is just a temporary workaround. > Да, использование nss-ldapd решает проблему. Нет, не решает, только маскирует.
http://sourceware.org/git/?p=glibc.git;a=commit;h=e04ad41831a292148eb9cc75d067c46f6e137545
glibc-6:2.9-alt5 -> sisyphus: * Mon Apr 20 2009 Dmitry V. Levin <ldv@altlinux> 6:2.9-alt5 - glibc-doc is no longer required by glibc-devel (closes: #17963). - Backported fix for__res_maybe_init() from trunk (closes: #19657).
(В ответ на комментарий №17) > - Backported fix for__res_maybe_init() from trunk (closes: #19657). Не уверен.. Обновил на тестовой машине glibc из Сизифа, обнулил и +i на /etc/resolv.conf , перезагрузил. ldap, естественно, не доступен. Вернул правильный resolv.conf, ldap по прежнему недоступен, nslcd пишет: resource is temporary unavalible. ПОсле перезапуска nslcd всё работает.
(In reply to comment #18) > (В ответ на комментарий №17) > > - Backported fix for__res_maybe_init() from trunk (closes: #19657). > Не уверен.. Не уверен, что backported, или не уверен, что closes? > Обновил на тестовой машине glibc из Сизифа, обнулил и +i на > /etc/resolv.conf , перезагрузил. > ldap, естественно, не доступен. > Вернул правильный resolv.conf, ldap по прежнему недоступен, nslcd пишет: > resource is temporary unavalible. Это уже что-то новое. > ПОсле перезапуска nslcd всё работает. А если вернуть nss_ldap?
(В ответ на комментарий №19) > > > - Backported fix for__res_maybe_init() from trunk (closes: #19657). > > Не уверен.. > > Не уверен, что backported, или не уверен, что closes? что closes ;) > > ПОсле перезапуска nslcd всё работает. > > А если вернуть nss_ldap? Установил дистрибутив от 17 числа (с nss_ldap). Первая загрузка -- глухое зависание до неработы numlock (вчера такое же одина раз было с nss-ldapd, Миша проинформирован). Перезагрузил, обновил glibc, init 1, обнулил resove, перезагрузил, всё работает. Сейчас с chattr попробую..
с chattr +i пустого resolve.conf после приведения его в норму после загрузки всё работает (с nss_ldap)
образ с nss_ldap и новым glibc работает нормально. Рекомендую в 5.0 ;)
*** Bug 19720 has been marked as a duplicate of this bug. ***
