CentOS 7 с графическим интерфейсом Вход в GNOME для стандартных пользователей возвращается к экрану входа

Машина с CentOS 7 не может войти в систему обычных пользователей через GNOME, но учетная запись root работает нормально.

Шаги к воссоздайте проблему.

  1. Выберите учетную запись пользователя и введите пароль и логин (учетная запись пользователя является частью группы wheel )
  2. Фоновое изображение отображается, но значки на рабочем столе отсутствуют
  3. Система простаивает в течение примерно через минуту он становится черным и возвращается к экрану входа в систему

Файл журнала Journalctl, когда стандартный пользователь выполняет вход, слишком велик для отображения здесь, но я заметил, что вижу эту конкретную строку 100 раз. Эта система не привязана к Active Каталог и не имеет никаких специальных файлов, добавленных в /etc/pam.d/ или добавленных / измененных в / etc / security / .

Mar 07 13:29:03 presstore fsmpm[3391]: pm_query_ldap: got request "uid_by_sid S-1-5-21-552760624-291916025-312552118-255638"

Я сделал снимки корневого каталога войдя в систему через journalctl -f и сравнив их со стандартным пользователем, выделяются следующие строки:

Mar 07 13:30:34 presstore gnome-session-binary[6766]: WARNING: Application 'nautilus-classic.desktop' failed to register before timeout
Mar 07 13:30:34 presstore gnome-session[6766]: gnome-session-binary[6766]: WARNING: Application 'nautilus-classic.desktop' failed to register before timeout
Mar 07 13:30:34 presstore gnome-session-binary[6766]: Unrecoverable failure in required component nautilus-classic.desktop
Mar 07 13:30:34 presstore at-spi-bus-laun[6980]: Failed to register client: GDBus.Error:org.gnome.SessionManager.NotInRunning: Unable to register client
Mar 07 13:30:34 presstore at-spi2-registr[6987]: Failed to register client: GDBus.Error:org.gnome.SessionManager.NotInRunning: Unable to register client
Mar 07 13:30:34 presstore at-spi2-registr[6987]: Unable to register client with session manager
Mar 07 13:30:34 presstore gdm-password][5138]: pam_unix(gdm-password:session): session closed for user animation
Mar 07 13:30:34 presstore org.a11y.atspi.Registry[6985]: XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
Mar 07 13:30:34 presstore org.a11y.atspi.Registry[6985]: after 21 requests (21 known processed) with 0 events remaining.
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: [ 1551994234.242747]: IMSettings-Daemon[6860]: INFO: Release the ownership of com.redhat.imsettings
Mar 07 13:30:34 presstore org.gtk.vfs.Daemon[6776]: A connection to the bus can't be made
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: Exiting...
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: [ 1551994234.242970]: GLib-GIO[6860]: CRITICAL **: Error while sending AddMatch() message: The connection is closed
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: [ 1551994234.243036]: GLib-GIO[6860]: CRITICAL **: Error while sending AddMatch() message: The connection is closed
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: [ 1551994234.243134]: IMSettings-Daemon[6860]: INFO: Unloading imesttings module: gsettings
Mar 07 13:30:34 presstore com.redhat.imsettings[6776]: [ 1551994234.243223]: IMSettings-Daemon[6860]: INFO: imsettings-daemon is shut down.

Список o еще кое-что, что я пробовал:

  1. Удалил папку .config стандартных пользователей
  2. Удалил стандартного пользователя и создал нового пользователя, к сожалению, проблема не исчезла
  3. Переустановил пакеты gnome с yum, переустановите gnome - * и перезапустил gdm

Я в растерянности, я всегда могу воссоздать сервер и установить карты Fibre Channel, сетевые карты, карты sas, внутренние драйверы рейда и конфигурацию различных компонентов, но я хотел бы решить проблему или хотя бы понять, почему это происходит и как это исправить.

Я думаю, что могу удалить /tmp/.X11-unix и / или /tmp/.ICE-unix , но это просто снимок в темноте.

Я считаю, что GNOME может не загружаться, потому что что-то еще замедляет процесс входа в систему настолько, что у GNOME может просто истечь время ожидания, но я не уверен. Причина, по которой я так думаю, заключается в том, что раньше сервер немного задерживался, а затем в конечном итоге входил в систему пользователя, но теперь эта задержка стала значительно дольше. Это может объяснить, почему root может войти в систему, потому что он обходит все проверки, выполняемые для других пользователей, даже если стандартные пользователи входят в группу wheel .

0
задан 8 March 2019 в 01:19
2 ответа

Это проблема с тех пор была решена, вот что случилось со всеми заинтересованными.

Немного предыстории ... В нашей текущей среде / настройке при монтировании тома SAN его содержимое отображается с задержкой для всех учетных записей, не являющихся root. Согласно компании, которая предоставляет двоичные файлы для тома SAN для подключения к машине CentOS, сервер должен быть привязан к Active Directory, чтобы удалять ложные запросы ldap.

Следовательно, если учетная запись пользователя без полномочий root пытается получить листинг, с помощью терминала или графического интерфейса GNOME, будет вызвана задержка этого листинга. Исправление проблемы достигается привязкой машины к Active Directory. Обратите внимание, что учетная запись пользователя может быть локальной для машины, и задержка все равно не будет.

Привязка машины к Active Directory устранила проблему, и журналы pm_query_ldap больше не присутствуют в / var / log / messages или journcalctl .

1
ответ дан 4 December 2019 в 15:44

Проверьте, есть ли у вас файл / etc / nologin, также поищите в / lib, / usr / lib, / run файл с таким же именем - я чувствую, что видел это раньше, я просто не могу вспомнить точное имя файла.

Если найдете, удалите и посмотрите, поможет ли это.

0
ответ дан 4 December 2019 в 15:44

Теги

Похожие вопросы