Вокруг экрана входа Astra Linux живут два похожих имени — fly-dm и fly-dm_greet. Когда графический вход не поднимается, полезно сначала понять, какой из этих процессов не работает и где искать его журнал.

Чем fly-dm отличается от fly-dm_greet

fly-dm — системный сервис, дисплей-менеджер Astra (юнит fly-dm.service, «The FLY login manager»). В типовой конфигурации родительский процесс работает от root, запускает X-сервер на отдельном виртуальном терминале и поднимает графическую форму входа. Сам он ничего не рисует.

fly-dm_greet — та самая форма входа (greeter). Отдельный процесс, который работает от служебного пользователя fly-dm и общается с сервисом: принятые логин и пароль greeter передаёт fly-dm, а тот проводит аутентификацию через PAM-стек (/etc/pam.d/fly-dm).

Вживую эта пара выглядит так:

root    1268  /usr/bin/fly-dm vt7
fly-dm  1552  /usr/lib/xorg/Xorg ... vt7 -logfile /var/log/fly-dm/Xorg.%s.log
fly-dm  1566  /usr/bin/fly-dm_greet

Поэтому когда «ломается экран входа», первым делом стоит понять, кто именно сломался: сервис, X-сервер или greeter. У каждого свой лог — о них ниже.

Из какого пакета /usr/bin/fly-dm_greet

$ dpkg -S /usr/bin/fly-dm_greet
fly-qdm: /usr/bin/fly-dm_greet

Бинарный файл принадлежит пакету fly-qdm («Fly Display Manager, GUI part»), а не fly-dm («service part»). Номера версий этих пакетов могут различаться.

«Отсутствует файл /usr/bin/fly-dm_greet»

Раз файл устанавливает fly-qdm, первым делом проверьте, установлен ли пакет и не повреждены ли его файлы. Пакет мог быть удалён вместе с Qt-зависимостями или обновиться не полностью.

Проверка и восстановление пакета:

$ sudo apt-get install --reinstall fly-qdm
$ dpkg -V fly-qdm

dpkg -V сверяет контрольные суммы установленных файлов с эталонными из базы пакетов. Пустой вывод — все файлы пакета на месте и совпадают с оригиналом. Строки с пометкой c относятся к правленым конфигам — на настроенной системе это нормально. Запускать проверку лучше под sudo, иначе часть путей ответит «Отказано в доступе». После переустановки перезапустите fly-dm (об осторожности с этой командой — ниже).

fly-dm_greet падает: где смотреть

Порядок разбора при падающем экране входа (segfault, циклический перезапуск, чёрный экран):

  1. journalctl -u fly-dm и /var/log/fly-dm.log — журнал сервиса: видно, что greeter завершился и с каким статусом, и как часто сервис его перезапускает.
  2. /var/log/fly-dm/Xorg.*.log — журнал X-сервера: если падает не greeter, а X, причина будет здесь (обычно видеодрайвер).

Быстрый, но не окончательный ориентир: если виден чёрный экран с курсором мыши, X-сервер уже запущен и проблема, вероятно, выше — в greeter или его теме. Если система постоянно возвращается в текстовый терминал, отдельно проверьте запуск X.

Пара слов про чтение Xorg-лога: ошибки в нём помечены маркером (EE), предупреждения — (WW), легенда напечатана в шапке самого лога. Быстрый отбор:

$ grep '(EE)' /var/log/fly-dm/Xorg.0.log

Свежий запуск пишется в Xorg.0.log, предыдущий лежит рядом в Xorg.0.log.old — полезно сравнить их, чтобы понять, появилась ли ошибка после обновления или жила и раньше.

Разбор типовых случаев

Greeter падает сразу после обновления системы. Возможная причина — незавершённая настройка пакетов или несогласованный набор Qt-библиотек. Сначала проверьте состояние пакетной системы:

$ dpkg --audit
$ sudo dpkg --configure -a
$ sudo apt --fix-broken install
$ sudo apt-get install --reinstall fly-qdm

Перед выполнением команд посмотрите предлагаемый план изменений. full-upgrade здесь не универсальное лечение: он обновляет систему целиком и при разрешении зависимостей может удалить установленные пакеты.

Падение после смены фона или темы экрана входа. Если greeter жил, а сломался после правки оформления, — вспомните, что меняли. Путь к фону задаётся в /etc/X11/fly-dm/backgroundrc: проверьте, что файл по этому пути существует и открывается просмотрщиком; вернуть заведомо рабочее состояние можно, откатив правку.

Пароль принят, но вместо рабочего стола — снова экран входа. Это login loop, и greeter свою часть уже выполнил: ломается запуск пользовательской сессии. Проверьте ~/.xsession-errors, свободное место (df -h) и владельца служебных файлов в домашнем каталоге. Например, владельцем ~/.Xauthority после неаккуратного sudo мог стать root — это видно в ls -la ~/.Xauthority.

Сторонние greeter-плагины. Если на устройстве установлен нестандартный плагин формы входа, после обновления fly-qdm проверьте его совместимость с новой версией. Плагину, собранному против изменившегося ABI, может потребоваться пересборка.

Экран входа не поднимается: как попасть в систему

Пока greeter падает, сама система обычно остаётся доступна. Войти можно с текстовой консоли (Ctrl+Alt+F2…F6, обычный текстовый login) или по SSH, если он настроен. Дальше — смотреть журналы и исправлять причину без перезагрузок вслепую.

Заодно стоит задать системе два контрольных вопроса — должен ли графический вход вообще подниматься:

$ systemctl get-default
graphical.target
$ systemctl is-enabled fly-dm
enabled

Если systemctl get-default отвечает multi-user.target, дисплей-менеджер и не обязан стартовать: это не поломка, а конфигурация системы — кто-то перевёл её в текстовый режим.

systemctl restart fly-dm: одна оговорка

sudo systemctl restart fly-dm перезапускает дисплей-менеджер вместе с графическими сессиями — открытые программы пользователей завершатся. Выполняйте с текстовой консоли (например, Ctrl+Alt+F2…F6) или по SSH, а не из-под графики. Проверка после перезапуска:

$ systemctl status fly-dm
● fly-dm.service - The FLY login manager
     Active: active (running)

Где лежит конфигурация

Основная конфигурация экрана входа лежит в каталоге /etc/X11/fly-dm/:

  • fly-dmrc — основной конфиг дисплей-менеджера;
  • backgroundrc — фон экрана входа;
  • Xsetup, Xstartup, Xreset — хуки на этапах старта и завершения сессии;
  • sessions — доступные типы сессий.

Редактировать всё это удобнее штатной утилитой fly-admin-dm (установлена по умолчанию). После правок перезапустите fly-dm — с той же оговоркой из предыдущего раздела.

Почему X и greeter работают не от root

Вернитесь к выводу ps из начала статьи: родительский процесс fly-dm работает от root, а X-сервер и greeter в типовой конфигурации запущены от служебного пользователя fly-dm. Greeter не останавливает систему при падении, потому что это отдельный процесс, который контролирует дисплей-менеджер. Непривилегированный пользователь нужен для другого: он ограничивает последствия ошибки или компрометации формы входа.

Отсюда диагностическое следствие. Файлы, которые пишут X и greeter, — те же Xorg-логи в /var/log/fly-dm/ — принадлежат пользователю fly-dm. Если права на этот каталог сбиты (после восстановления из резервной копии или неаккуратного chown), графический вход может не подняться именно из-за невозможности писать логи — проверьте владельца каталога командой ls -la /var/log/fly-dm/.

Источники