GDM зависает, когда корневой каталог недоступен

Проблема с/etc/gdm /*

В рассмотрении Справочника менеджера по оформлению GNOME я заметил несколько каталогов под /etc/gdm с различными сценариями и таким.

Существует несколько ссылок в этих каталогах к $HOME. Я попытался бы комментировать их, чтобы видеть, можно ли избавиться от доступа к $HOME.

Для отладки проблемы далее, я был бы склонен бросить несколько set -x строки наверху различных сценариев в этих каталогах для наблюдения, что работает до "полномочий, отклоненных" сообщения.

Сценарий в каталогах - все bash сценарии в моих системах.

/etc/gdm/custom.conf

параметр отладки

Существует параметр отладки в этом файле, который отключен по умолчанию. Попытайтесь включить его, сообщения обнаружатся в /var/log/messages.

[debug]
Enable=true

Отключите поверхности во входе в систему

Я также попытался бы отключить включение поверхностей всего пользователя при входе в систему gdm в браузере поверхности.

[greeter]
IncludeAll=false

Вместо того, чтобы отключить его Вы могли экспериментировать с отключением только одного из Ваших трудных пользователей путем добавления их к этому списку:

Exclude=<some user>

Обновление № 1 - проблема Bugzilla

Проблема, кажется, связана с этой ошибкой, зарегистрированной против Системы отслеживания ошибок Red Hat, названной:

• Ошибка 908337 - GDM зависает с входом в систему krb5 и корневым каталогом NFS4+krb5p прежде, чем попросить пароль

Нет никакого разрешения, но как часть ошибки был тест, чтобы подтвердить испытание этой ошибки.

Когда проблема обнаруживается, GDM, по-видимому, создает каталог кэша здесь: /var/run/user/42. Удаление этого каталога позволяет входу в систему GDM продолжаться. OP подтвердил это в комментариях.

Обновление № 2 - возможные обходные решения

Был 2-й комментарий (мной) к некоторым дополнительным ссылкам с предложениями для работы через проблему. Ссылка названа:

• Как смонтировать доли NFS Kerberized как член Active Directory CSCF

конкретно в этом разделе:

• Обновите стопку PAM для монтирования персонального дискового пространства NFS при входе в систему

имел некоторые модификации к установке PAM, которая могла бы устранить проблему.

Одна вещь, для которой gdm мог бы посмотреть в корневых каталогах, состоит в том, чтобы получить фотографии пользователей для отображения в списке пользователей.

Я думаю, что OpenSUSE использует gdm 3.6.2, который корректен?

Две вещи я предлагаю делать:

1. Включите отладку, регистрирующуюся согласно gdm debugsection, попытайтесь повторно выполнить gdm и затем посмотрите, существует ли что-либо полезное в Ваших системных журналах
2. Попытайтесь отключить список пользователей согласно Простой Конфигурации Зазывалы

Это могло бы искать .dmrc или что-то подобное для загрузки настроек сеанса пользователя из. Для проверки присоедините к процессу gdm с strace и проверьте, какие файлы это пытается открыть (и где это зависает). Вы, вероятно, хотите использовать что-то как:

strace -f -o /path/to/logfile PID_OF_GDM

-f дети трассировок обрабатывают также, -o перенаправления регистрируются в файл (вместо этого stderr).

Если это верно, помещение файла в пользовательский каталог, прежде чем это будет смонтировано, должно устранить проблему (но пользователь не сможет изменить его).

Если не легко возможно присоединить к GDM, прежде чем это откажет, можно отредактировать средство запуска (или соответствующая systemd единица или - если Вы все еще придерживаетесь sysvinit - init сценарий).

Однако самый безопасный способ поймать его состоит в том, чтобы заменить gdm со сценарием обертки, который назвал бы исходный двоичный файл (переименованный к, например. gdm.bin). Затем, неважно, как менеджер порожден, это будет прослеженным. Вы могли бы также хотеть использовать исключительно именованный файл для вывода - просто используют $$ и/или `date --iso=ns` в сценарии обертки:

#!/bin/bash
strace -f -o /path/to/gdm-${$}-$(date --iso-8601=ns).strace \
    /path/to/original/gdm.bin