Вопрос или проблема
Я создаю диспетчер отображения (dm) на Python, который ждет запуска Xorg, чтобы запустить GUI.
Python
(упущен ненужный код, такой как виджеты, классы и функции)
import os
(дополнительные импорты PyQt6 и т.д.)
.......
class LoginWindow( QMainWindow ):
def __init__(self):
super().__init__()
# Сделать окно полноэкранным
self.setWindowFlags(Qt.WindowType.FramelessWindowHint |
Qt.WindowType.WindowStaysOnTopHint
)
..........
.......... (ненужный для проблемы код)
def cancel(self, window):
if not window :
...
def start_x11():
xorg =subprocess.run("Xorg :0 -nolisten tcp -background none -logfile /var/log/mydm/xorg.log vt1",shell=True)
return xorg
def start_user_session(username) :
loginctl = subprocess.run(f"loginctl enable-linger {username}",shell=True)# ,capture_output=True)
#print(loginctl)
if loginctl.returncode == 0 :
subprocess.run(f"sudo -u {username} dbus-launch startxfce4",shell=True)
if __name__ == "__main__" :
if start_x11().returncode == 0 :
app = QApplication(sys.argv)
app.setStyleSheet('''
QPushButton#loginDockButton {
border: none;
padding: 0px;
margin: 0px;
}
''')
window = LoginWindow()
window.show()
sys.exit(app.exec())
Как вы можете видеть, я использую subprocess.run(), чтобы запустить Xorg.
А когда спросил у ИИ о решении проблемы, мне было рекомендовано запустить:
subprocess.run("loginctl enable-linger {username}",shell=True)
Согласно этому ИИ, это позволяет дочерним процессам пользователя работать, даже если он вышел, чтобы предотвратить закрытие процесса dbus. (Хотя все еще интересно, как это может помочь 🤔)
Сервис Unit
[Unit]
Description=mydm
[email protected]
After=systemd-user-sessions.service plymouth-quit.service
Requires=systemd-logind.service
[Service]
ExecStart=/usr/bin/python3 /etc/mydm/src/mydm_login.py
Restart=always
RestartSec=3
StandardOutput=syslog
StandardError=syslog
TTYPath=/dev/tty1
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
[Install]
WantedBy=graphical.target
Должен признать, что код сервиса unit был полностью сгенерирован ИИ, потому что у меня не было никакого представления о том, как работают unit-файлы и ни о systemd, ни о systemctl
Лог-файл
После нескольких минут печали и горя от того, что не вижу своего GUI, я решил заглянуть в лог-файл от Xorg и получил следующее:
[ 3671.154] Current Operating System: Linux MrDikxon 6.13.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 08 Feb 2025 18:54:55 +0000 x86_64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
grep EE /var/log/mydm/xorg.log
[ 3671.154] (EE) systemd-logind: failed to get session: PID 4060 does not belong to any known session
[ 3671.171] (EE) Failed to load module "fbdev" (module does not exist, 0)
[ 3671.172] (EE) Failed to load module "vesa" (module does not exist, 0)
[ 3671.186] (EE) open /dev/dri/card0: No such file or directory
[ 3671.191] (II) Initializing extension MIT-SCREEN-SAVER
[ 3671.193] (EE) AIGLX error: dlopen of /usr/lib/dri/i965_dri.so failed (/usr/lib/dri/i965_dri.so: cannot open shared object file: No such file or directory)
[ 3671.193] (EE) AIGLX error: unable to load driver i965
grep WW /var/log/mydm/xorg.log
[ 3671.154] (WW) The directory "/usr/share/fonts/misc" does not exist.
[ 3671.154] (WW) The directory "/usr/share/fonts/TTF" does not exist.
[ 3671.154] (WW) The directory "/usr/share/fonts/OTF" does not exist.
[ 3671.154] (WW) The directory "/usr/share/fonts/Type1" does not exist.
[ 3671.154] (WW) The directory "/usr/share/fonts/100dpi" does not exist.
[ 3671.154] (WW) The directory "/usr/share/fonts/75dpi" does not exist.
[ 3671.169] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
[ 3671.171] (WW) Warning, couldn't open module fbdev
[ 3671.172] (WW) Warning, couldn't open module vesa
[ 3671.186] (WW) Falling back to old probe method for modesetting
При выполнении команд для (NI,??) не получено никакого вывода.
Это мой первый опыт работы с Xorg или sysmted, так что я действительно не знаю, что могу сделать. Так что я еще ничего не пробовал, а темы на unix & linux stackexchange не кажутся прямо связанными с тем, что мне нужно
Ответ или решение
Создание дисплейного менеджера (DM) на Python на основании Xorg — это довольно сложная задача, особенно если вы ранее не работали с Xorg и systemd. Работа с такими системами требует понимания принципов их работы, а также особенностей интеграции с операционной системой Linux. Давайте подробно разберем теорию, примеры и практическое применение создаваемого вами решения.
Теория
Xorg — это сервер X Window, который предоставляет основной графический интерфейс во многих UNIX-системах, включая Linux. Он отвечает за отображение графического интерфейса пользователя и взаимодействие с аппаратными устройствами, такими как видеоадаптеры и мониторы.
Display Manager (DM) — это программное обеспечение, которое управляет пользовательскими сессиями Xorg. Он запускается при запуске системы, и его основная задача — представить пользователю экран входа в систему и запустить соответствующую пользовательскую сессию.
Основные проблемы при работе с DM и Xorg:
- Управление сессиями: Сессии пользователей должны корректно инициироваться и завершаться. Обычно это связано с использованием systemd и loginctl.
- Зависимости: Дисплейный менеджер должен ждать инициализации Xorg перед тем, как начать выполнение GUI.
- Аппаратная поддержка: Убедитесь, что все необходимые драйверы установлены и корректно функционируют, особенно для видеовывода.
Ваша текущая реализация использует subprocess для запуска Xorg, а также функции systemd через subprocess для управления пользовательскими сессиями. Это стандартная техника для управления процессами в Python.
Пример
Теперь рассмотрим ваш код и логи:
-
Код: Запуск Xorg с помощью
subprocess.run
и управление пользовательскими сессиями с помощьюloginctl enable-linger
. Это было предложено, чтобы обеспечить непрерывную работу дочерних процессов при выходе пользователя из системы. -
Отчеты о логах: В логах Xorg есть несколько ошибок:
systemd-logind: failed to get session
: Похоже, процесс Xorg не связан с активной сессией. Это может быть связано с неправильным управлением сессиями через systemd.Failed to load module "fbdev", "vesa"
: Это говорит о том, что в системе отсутствуют модули fbdev и vesa. Возможно, они не установлены, либо не нужны для вашего оборудования.open /dev/dri/card0: No such file or directory
: Кажется, отсутствует доступ к видеоустройству. Это может быть связано с драйверами или правами доступа.AIGLX error: unable to load driver i965
: Указывает, что драйвер Intel i965 для AIGLX не найден. Проверьте, что требуемые видео-драйверы установлены в системе.
Применение
-
Управление сессиями: Убедитесь, что ваш сценарий правильно управляет запуском и завершением сессий. Используйте средства systemd для обеспечения корректной инициализации и завершения всех необходимых процессов.
-
Установка нужных модулей: Проверьте и установите все необходимые системные модули и драйверы. Это включает в себя модули fbdev, vesa и драйверы графического оборудования, такие как Intel i965.
-
Настройки unit-файла systemd: Поскольку unit-файл был сгенерирован автоматически, его настройки требуют проверки. Особое внимание стоит обратить на параметры TTY и Restart для обеспечения корректного запуска и остановки DM.
-
Правильная настройка прав доступа: Убедитесь, что ваш скрипт запускается с правильными правами доступа, необходимыми для выполнения всех низкоуровневых операций, связанных с графическим выводом и управлением сессиями.
-
Совместимость оборудования: Убедитесь, что ваш DM совместим с установленным на системе оборудованием. Это также может включать в себя правки конфигурационных файлов Xorg, таких как
/etc/X11/xorg.conf.d/
. -
Обратная связь и проверка ошибок: Внедрите в код обработку ошибок и ведение логов, чтобы диагностировать проблемы по мере их возникновения. Это поможет более четко понимать, что именно не срабатывает в процессе запуска.
Создание дисплейного менеджера на основе Python и Xorg — это гибкая, но сложная задача, требующая внимательного подхода. Постоянная проверка логов, очистка системы от ненужных модулей и установка всех нужных пакетов — ключ к успешному развертыванию рабочего решения. Если что-то не получается, можно обращаться к документации Xorg, systemd и связанных технологий или к сообществу специалистов Linux за помощью и дополнительными примерами.