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

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

fly-dm — системный сервис, дисплей-менеджер Astra (юнит fly-dm.service, «The FLY login manager»). Он работает от root, занимает виртуальный терминал vt7, поднимает 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»). Версии у этих пакетов независимые, поэтому в dpkg -l у них могут быть разные номера.

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

Раз файл ставит fly-qdm, отсутствие бинаря означает, что пакет удалён или повреждён. Сюда обычно приводит чистка «лишних» Qt-пакетов: 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 падает сразу после обновления системы. Самая частая картина: обновление прошло не целиком, и fly-qdm остался с Qt-библиотеками другой версии. В journalctl -u fly-dm это выглядит как перезапуск greeter сразу после старта, раз за разом. Лечение — довести обновление до конца и вернуть согласованный набор пакетов:

$ sudo apt-get update && sudo apt-get full-upgrade
$ sudo apt-get install --reinstall fly-qdm

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

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

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

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

Пока 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+F1…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 из начала статьи: от root там работает только сам сервис fly-dm, а X-сервер и greeter запущены от служебного пользователя fly-dm. Это штатное разделение привилегий: форма входа, которая обрабатывает ввод с клавиатуры и рисует на экране, прав root не имеет, поэтому её падение не роняет систему целиком.

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