systemd --user support files

[gdamjan]

• adds a sway-session.target that binds to graphical-session.target
  (see man systemd.special)
• also adds a 10-systemd script that should (must?) be included from sway
  that starts imports the sway environment variables into the systemd
  --user instance, and then starts sway-session.target

The idea is that, any --user units that are wanted by either
sway-session.target or graphical-session.target will be started when
sway runs, and will have the correct environment from sway too.

[gdamjan]

This is work-in-progress, comments welcome.

[gdamjan]

one example how systemd --user support would be used is, a waybar unit file:

[Unit]
Description=Highly customizable Wayland bar for Sway and Wlroots based compositors.
Documentation=https://github.com/Alexays/Waybar/wiki/
PartOf=graphical-session.target

[Service]
Type=simple
ExecStart=/usr/bin/waybar

[Install]
WantedBy=sway-session.target

when enabled, this unit would start waybar automatically when sway starts, and stop when graphical-session.target stops.

Similarly it could be used for swayidle, if it would support config files … as it is now, it would be weird to edit the unit file to change swayidle options. Alas, I have an example for that too.

[ddevault]

Thank you, but I'd rather not give a preference to any particular init system. This is the sort of thing you should pitch to your Linux distro.

[ascent12]

Instead of sway calling systemctl, you'd want to have it so systemd calls sway, like any other normal service.
Weston has an incomplete example of it: https://gitlab.freedesktop.org/wayland/weston/merge_requests/39 which you could take inspiration from.
But I also agree that we probably don't need a unit file upstream.

I don't know whether we want to add optional sd_notify support into sway, so that systemd is capable of knowing when sway has finished its startup and can order units after that. It'd be a trivially small amount of code, but it depends on whether you want any direct systemd things in the code.

[gdamjan]

@ascent12 from my research it's not easy to start sway/weston as a --user service from a login manager, yet -- so you'd need to login via agetty (edit: if that even works), which is meh. Otherwise I agree, that would be a nicer approach.

[gdamjan]

Let me just formally disagree with the decision here (before I go on with other things):

• the support I added is optional, doesn't subtract from any other OS at all
• I don't know of other init systems that have a --user session management, and both Gnome and KDE (at least), are using and improving their systemd --user support. So it's not a preference for a init system, it's about using features that exist on a platform vs not using them
• like it or not, systemd is a standard feature on Linux desktops including (Debian, Ubuntu, Arch, Fedora, RHEL and OpenSuse), but again this change doesn't subtract from any other OS.
• sending this same change to ALL distros is a huge effort, and promotes platform fragmentation. I'd claim that window managers supporting systemd linux distros should support graphical-session.target properly.

With that said, I'm off to fight other issues.

[emersion]

I don't know whether we want to add optional sd_notify support into sway, so that systemd is capable of knowing when sway has finished its startup and can order units after that. It'd be a trivially small amount of code, but it depends on whether you want any direct systemd things in the code.

Add this to your config:

exec systemd-notify --ready || true

[jpsamaroo]

Maybe the wiki would be a better place for this script? It already has some distro-specific docs there (for Debian/Ubuntu), so I feel like putting init-specific scripts there would make sense.

[ddevault]

+1, wiki would be a great place for this

[gdamjan]

https://github.com/swaywm/sway/wiki/Systemd-integration