Как правильно сделать старт GUI через systemd

Как правильно сделать старт GUI через systemd

Никак. /thread

через правило udev стартуем скрипт который ждет запуска xorg и запускает GUI

Сделаю вид, будто я этого не заметил...

Какие альтернативы? В этих интернетах советуют еще городить свой демон чтобы он ждал устройство и запускал что надо. Разовое действие через startup не годится т.к. При переходе в ждущий режим и обратно, устройство отключантся и заново подключантся.

как вариант написать скрипт python/perl или бинарь и ловить событие от udev-монитора, а сам скрипт/бинарь в автостарт WindowManagera - примерно вот так:

#!/usr/bin/perl
 
use strict;
use warnings;

use Udev::FFI;

my $udev = Udev::FFI->new() or
    die "Can't create Udev::FFI object: $@.\n";
 
my $monitor = $udev->new_monitor() or
    die "Can't create udev monitor: $@.\n";

# можно добавить фильтр
#$monitor->filter_by_subsystem_devtype('usb');

if($monitor->start()) {
    for(;;) {
        my $device = $monitor->poll(); # blocking read
        # если совпадает индетификатор девайса (vip, pid или пр.) - то запускаем приложение
    }
}

Но... Ведь для этого и сделан udev... Он как раз ловит события.

С systemd такой фокус проходит лишь частично, GUI стартует, после чего по таймауту процесс убивается силами systemd

Разовое действие через startup не годится т.к. При переходе в ждущий режим и обратно, устройство отключантся и заново подключантся.

написать правило udev, которое будет стартовать сервис systemd хдд

Скорей уж в правиле udev мониторить наличие systemd и стартовать сервис, а в сервисе уже контролировать наличие адаптера... Но не убьет ли его опять сам системд.

так udev monitor и есть часть udev'a и также ловит собития через libudev - только в собственном приложении/скрипте. если очень хочется можно написать демона на c/c++/Rust - строк ~30 получится

пусть udev мониторит подключение адаптера и стартует сервис, а при отключении останавливает (какая-то наркомания)

по идее, в системд же настраиваются как-то сетевые адаптеры, там и реакция на подключение/отключение наверн есть, вот по аналогии и сделать (но я не шарю)

вот именно что писать ничего не хочется и смысла не вижу пока. если все равно используется udev. Вобще c udev проблем нету, проблема когда системд в системе.

intelfx шарит, но он сказал что так неправильно.

Программка привязана к наличию bluetooth адаптера в системе, нет адаптера - программа не запускается, появился адаптер - запускаем программу.

Да systemd заточен на запуск сервисов, но там же есть .device еще есть установка переменных окружения, проверку наличия xorg тоже как-то можно сделать через target например.

Нет, никто тебе не запретит захардкодить в .service значение $DISPLAY, каким-то образом пробросить authority и запускать что хочешь, но это костыль и хардкод. Тебе никто не гарантирует, что твой скрипт запустится строго после запуска X-сервера (After=display-manager.service не поможет), ты никак не получишь остальные переменные окружения из графической сессии, у тебя сломается polkit и т. п.

Если для тебя это всё не проблема — хардкодь, кто ж тебе помешает. Но «правильно» эта задача с помощью systemd не решается никак.

через запуск из udev работает и результат устраивает, как сделать чтобы systemd не убивал ее?

Ну тогда нет проблем. Просто сделай Type=simple (или Type=forking) юнит и запускай его systemctl start'ом из RUN, чего уж проще.

Если нужно, чтобы systemd сам прибивал твою программу при отключении железки, тогда TAG+="systemd", ENV{SYSTEMD_WANTS}+="foo.service".

спасибо буду пробовать

Написал такой юнит bluetooth.service:

[Unit]
Description=Start bluez-tray applet
BindsTo=sys-subsystem-bluetooth-devices-hci0.device

After=bluetooth.target
Requires=graphical.target bluetooth.target

[Service]
Type=forking
ExecStart=/usr/bin/bluetooth.sh

В принципе к bluetooth.target можно не привязываться наверное, но вопрос по строчке BindsTo=, можно ли там указать вместо hci0 знак подстановки? может есть @ или что-то подобное?