Чем тебя не устраивает обычный autostart в DE?

Копай в сторону запуска пользовательского экземпляра systemd в рамках сессии.

прописать в Requires= службу данного графического интерфейса ??

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

при выключении граф.среды выключатся твой сервис, т.к. Requires пеестает выполняться.

Нет, графические сессии запускаются вообще вне контроля systemd, не отдельной службой, поэтому с «привязкой» всё вообще сложно.

службу данного графического интерфейса

Такой не существует.

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

Requres= работает не так.

придумай свой target и делай sudo systemctl isolate custom-some-de.target

systemd тут ни при чём. Используй autostart в DE и кастомный xsession для WM

с «привязкой» всё вообще сложно

XDG_SESSION_DESKTOP

Речь совсем-совсем не об этом.

systemd умеет управлять сервисами в пространстве обычного пользователя, есть ключ для этого "--user".

К примеру, у меня идет запуск несколько разных conky и монтирование EncFS с помощью systemd.

Тред не читай@отвечай

systemd: привязка сервисов к графической среде (комментарий)

Я не согласен с ответом «нет». Хотя графические сессии не запускаются отдельной службой systemd, это не значит, что нельзя решить проблему ТС с systemd.

Есть несколько вариантов:

• Использовать Condition* и указывать файлы/директории/сокеты, специфические для каждого DE/WM.
• Передавать в скрипт-враппер переменную окружения XDG_SESSION_DESKTOP

Для X приложений нужно позаботиться о переменных DISPLAY и XAUTHORITY, это тоже предусмотрено: https://wiki.archlinux.org/index.php/Systemd/User#DISPLAY_and_XAUTHORITY

А можно не натягивать сову на глобус и сделать это штатными средствами DE или xsession

всем в данном треде посвящается

Понимаешь ли, инстанс systemd --user общий на все сессии пользователя. Семантически, да и технически тоже, время жизни пользовательского инстанса systemd «накрывает» время жизни любой из сессий. Поэтому любая передача информации из конкретной сессии в systemd (а $XDG_SESSION_DESKTOP и тем более $DISPLAY — это как раз такая информация) заранее обречена на дикие костыли.

systemd --user просто не предназначен для таких задач by design, поэтому я и говорю «нет».

у меня идет запуск несколько разных conky […] с помощью systemd.

А теперь загляни в лог, когда у тебя не запущены иксы, там будет очень много попыток запустить твой сервис, которые завершились неудачно.

Не всё можно сделать штатными средствами DE или xsession.

Мы не знаем, насколько ТС нужно гибкое управление запускаемыми сервисами.

Если нужны кастомные команды для выключения сервисов, авторестарт упавших сервисов, зависимости от других сервисов, запустить с недефолтными Capabilities и т.д., то systemd будет вполне оправдан.

Может, он предпочитает не использовать лишние сущности, если уже есть systemd.

В любом случае, выбор инструмента — за ТС, в этой теме лишь демонстрация способов решения проблемы.

О'кей, дружок. Инициатор, как известно, имеет пассивную половую связь с инициативой. Покажи мне решение этой проблемы через systemd-юниты. И так, чтоб всё работало, и зависимости не валились.

Эти вопросы уже обсуждались:

https://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html

https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html

В целом, Леннарт сказал:

We want to move from a per-session to a per-user scheme to simplify

things, not making it moer complicated...

А пока там были указаны work-arounds, как же всё можно сделать это с помощью systemd. Не видно, чтобы разработчики systemd были столь категорично негативно настроены.

Если ТС не собирается запускать несколько разных DE одновременно из-под одного юзера, то какие ещё подводные камни могут быть? При смене DE (logout/login) сработает скрипт /etc/X11/xinit/xinitrc.d/50-systemd-user.sh, который обновит переменные окружения.

У меня нет цели любым способом переубедить тебя. Если ТС выберет запуск сервисов с помощью systemd, и в итоге он самостоятельно или общими усилиями с форумчанами решит свою проблему, то можешь спросить его, какое получилось конечное решение.

Конечное решение у него выглядит красиво. Но это его решение, по сути, заключается в том, что сессия превращается в синглтон и привязывается ко времени жизни manager-а (пользовательской копии systemd). Это, безусловно, будет работать, и это очень хорошая идея. Но в настоящий момент это только идея, и мы имеем все проблемы, описанные мной.

то какие ещё подводные камни могут быть? При смене DE (logout/login) сработает скрипт /etc/X11/xinit/xinitrc.d/50-systemd-user.sh, который обновит переменные окружения.

Подводный камень ровно один, и подводным он становится после того, как привязывается юзеру к шее.

Запуск сессии никак не отслеживается с точки зрения systemd. Нельзя написать Requires=сессия, или After=сессия. Юниты из systemd --user стартуют во время логина пользователя и параллельно с запуском DE, а иногда очень сильно до этого и даже до первого входа пользователя в систему (linger). Нет такого юнита, цели или прочего, к чему можно было бы привязаться в качестве триггера или точки синхронизации.

Да, /etc/X11/xinit/xinitrc.d/50-systemd-user.sh экспортирует $DISPLAY в окружение systemd, и по аналогии можно экспортировать любую другую переменную, но ты разве не видишь здесь огромную такую гонку?

Досадная недоработка, планируете исправлять?

Почитай всё, что я написал в топике. У Леннарта есть «große plane», и это прекрасно, но до него как пешком до Луны. Что делать сейчас — не очень понятно. Люди изобретают свои наборы костылей различной степени пригодности к эксплуатации, а среди DE — даже в GNOME (который всегда был пионером нововведений) спускают всё на тормозах и обкостыливают проблемы.

У меня есть пара идей, что можно сделать, чтобы всё хоть как-то починить, но я ленивая жопа и идеи пока что тоже идеи.

но ты разве не видишь здесь огромную такую гонку?

Да, верно, гонка есть и она отлично себя проявляет. Поэтому я и советовал использовать Condition*.

У меня для запуска GUI-приложений предварительно через systemd.path отслеживается наличие пути $XDG_RUNTIME_DIR/kdeinit5__0, идёт обновление переменных окружения для сессии, и сервисы запускаются, когда KDE5 уже загружено.

Также можно воспользоваться таймером и немного задержать запуск скрипта-враппера. Просто, но ненадёжно.

systemd: привязка сервисов к графической среде (комментарий)

Ну какой к чертям Condition=? Гонка никуда не уходит, Condition= — это одноразовая проверка, а не триггер.

через systemd.path отслеживается наличие пути

Это уже гораздо более правильно. Но это тот самый дикий костыль, о которых я писал вначале.

Ну какой к чертям Condition=? Гонка никуда не уходит, Condition= — это одноразовая проверка, а не триггер.

Для связки с Restart=always, чтобы тихо скипало, когда DE/WM не запущены, а не репортило ошибки. Можно сделать более грамотно. Думаю, понадобится закрытие этого фич-реквеста https://github.com/systemd/systemd/issues/3642 и некоторых других.

Это уже гораздо более правильно. Но это тот самый дикий костыль, о которых я писал вначале.

Согласен. Лучше, как писал Леннарт, запускать в таком случае DE или WM через systemd. Вот есть наработки для KDE/Plasma https://github.com/KDE/plasma-systemd-integration. К сожалению, они в своё время остановились, потому что в systemd не хватало некоторых вещей, и плюс нужно кооперироваться с DM (хотя бы с SDDM). Надеюсь, у меня дойдут руки продолжить этот проект. А пока работаем с тем, что имеем.

вне контроля systemd

Как так то?? Это вообще законно??!