automatischer Start von User-Services für X11/wayland sessions:
Der grundlegende Unterschied zwischen deinem Setup und diesem Ansatz ist soweit ich sehe (Plasma-User mögen mich gerne korrigieren):
- im Ansatz von extra/plasma-workspace³ wird die Wayland-Session als User.service gestartet
| System Bereich¹ | -> logind->user-dbus->user_bereich
| User-Bereich² | -> plasma-*.services und targets.
- dein Ansatz startet die Wayland-Session aber im System-Bereich
| System-Bereich | logind->autologin+wayfire.service->user-dbus->user_bereich
| User-Bereich | du würdest hier gerne was starten abhängig von deinem wayfire.service
(¹ System-Bereich bezieht sich auf alles was mittels: systemctl --system <aktion> gehandhabt wird, ² User-Bereich dann auf alles systemctl --user <aktion>, also $HOME/.config/systemd/user/)
Das aber ist ja das Problem. Wir haben gesehen: User-Units können sich nicht (After,Wants,Require) auf System-Units beziehen. Dein wayfire-Unit ist aber eine System-Unit. Der Plasma-Ansatz hingegen kann sich auf relevante Units beziehen, da das eben alles User-Units sind. Wird das klar?
Im Plasma-Ansatz wäre es in der Tat wohl recht einfach z.B. via Unit-Files ein Terminal oder Firefox starten zu lassen, da daß eben After=plasma-plasmashell.service erfolgen kann. In deinem Ansatz (und meinem Test) geht das eben nicht, wir müssen uns für die "richtige Start-Position" mit Dingen wie Path oder Conditions rumschlagen (erfolglos).
Ich denke, wenn du wirklich deinen Versuch "autostart von GUI-Programmen via systemd-user-Units" verfolgen willst **dann bleibt dir nichts anderes übrig als deinen Start von wayfire auch in den User-Bereich zu verlagern.**
Also das autologin vom Start des wayfire.services zu trennen:
| System-Bereich | ->logind->autologin von brikler->user-dbus->user_bereich
| User-Bereich | wayfire.service->[kitty,firefox].service(s)
Das sehe ich die als die einzig handhabbare (aus systemd-Sicht) Möglichkeit an. Um eben mit dem Abhängigkeits-Mechanismus des init-Daemons arbeiten zu können.
brikler ich denke, da muß man ein eigenes target erstellen, damits funktioniert.
Targets spielen da (als Ursache/Lösung) AFAIK keine Rolle, da Targets ja "nur" sowas wie "Namespaces zum Gruppieren von Units" sind. Targets werden AFAIK auch immer "erreicht", selbst wenn darin gruppierte Units fehlschlagen. Das haben wir ja gesehen, unsere Units funktionieren nicht, trotzdem wird das (user)default.target "erreicht". An Targets können halt keine Unit-Bedingungen geknüpft werden.
Targets können nur die Reihenfolge/Bedingungen anderer Targets regeln, wobei jedes Target dann einen eigenen Satz von Units haben kann. Wenn du (mein Vorschlag) den wayfire.service in den User-Bereich verlagerst, dann könntest du zwei (User)-Targets haben:
graphical-session.target ( WanteBy wayfire.service)
graphical-autostart.target (WantedBy kitty.service, WantedBy firefox.service, ...)
graphical-autostart.target kann dann Requires=graphical-session.target haben. Das garantiert das z.B. kitty.service darin erst nach wayfire.service gestartet wird.
Anhang
Hilfreiche Befehle IMO:
$ systemctl --user list-unit-files
$ systemctl --user list-dependencies
$ systemd-analyze --user blame
$ systemd-analyze --user critical-chain (und auch plot -> svg-Image)
³ Der betreffende User-Service von Plasma (Paket extra/plasma-workspace) sieht so aus:
/usr/lib/systemd/user/plasma-plasmashell.service
[Unit]
Description=KDE Plasma Workspace
After=plasma-ksmserver.service plasma-kcminit.service
PartOf=graphical-session.target
StartLimitIntervalSec=60s
StartLimitBurst=3
[Service]
ExecStart=/usr/bin/plasmashell --no-respawn
Restart=on-failure
Type=dbus
BusName=org.kde.plasmashell
Slice=session.slice
TimeoutSec=40sec
[Install]
WantedBy=plasma-core.target