ℹ️ This guide is community-maintained. Please don't open issues if it doesn't work.

On systemd based Linux distributions, systemd can be used as an alternative way to start and manage user services and applications. Some general examples of services managed by systemd include gpg-agent, pulseaudio, dbus, etc, but in the case of sway, such services may also include waybar, swayidle, mako, and similar. Note that this method works for both X11 and Wayland programs.

In order to integrate sway with systemd and start user applications automatically when sway starts, we need to configure a sway session target that will also bind to the standardgraphical-session.target user target. This allows services to be started by systemd after sway launches by specifyingWantedBy=sway-session.target orWantedBy=graphical-session.target in the application's systemd unit file.

To configure the sway session target, place the following systemd unit file either locally at~/.config/systemd/user/sway-session.target, or globally for all users at/etc/systemd/user/sway-session.target:

[Unit]Description=sway compositor sessionDocumentation=man:systemd.special(7)BindsTo=graphical-session.targetWants=graphical-session-pre.targetAfter=graphical-session-pre.target

In order for the unit file to work properly, add the following lines to either/etc/sway/config.d/10-systemd which will include it in the default config, or add them to the end of the user's config file:

exec"systemctl --user import-environment {,WAYLAND_}DISPLAY SWAYSOCK; systemctl --user start sway-session.target"exec swaymsg -t subscribe'["shutdown"]'&& systemctl --user stop sway-session.target

This imports all of sway's environment variables into the systemd user manager, allowing its services to access these variables (for example the D-Bus session address), and then starts the sway session user target.

Note that thesystemctl commands must be run synchronously and can't be split into twoexec statements, since otherwise the session target may be started beforesystemctl import-environment is complete, and services that require certain variables will fail to run.

To walkthrough the stages of how this works:

• The user logs in via sddm or getty and the systemd user manager is automatically started (by pam_systemd and logind).
• When sway is run, it will import the environment variables into the systemd user manager and start the sway session target.
• The systemd user manager will then start all the services that depend on that target, and will provide them access to the imported env variables.

If you'd like sway's output to be handled by journald (like a systemd service),systemd-cat can be used for this:

exec systemd-cat --identifier=sway sway

You can print these logs via:

journalctl --user --identifier sway

Using--follow and--boot might be handy.journalctl(1) for details.

⚠️ Unsupported instructions

Running Sway as a systemd service is not supported, nor recommended, nor required for anything. It may break your setup if you're not familiar enough with systemd.

See#5160 for finer details on some discussion around this.

Place the following unit file either at~/.config/systemd/user/sway.service or/etc/systemd/user/sway.service:

[Unit]Description=sway - SirCmpwn's Wayland window managerDocumentation=man:sway(5)BindsTo=graphical-session.targetWants=graphical-session-pre.targetAfter=graphical-session-pre.target[Service]Type=simpleEnvironmentFile=-%h/.config/sway/envExecStartPre=systemctl --user unset-environment WAYLAND_DISPLAY DISPLAY # This line make you able to logout to dm and login into sway againExecStart=/usr/bin/swayRestart=on-failureRestartSec=1TimeoutStopSec=10

This service file will load environment variables from~/.config/sway/env, aKEY=VALUE file. That's a good place to put variables such as_JAVA_AWT_WM_NONREPARENTING=1 orCLUTTER_BACKEND=wayland (note: no need for export there, that is not a shell file).

Now, you want your login manager to start the service via systemd, and not sway directly. In order to do that, it's easiest to just create a new wayland session in/usr/share/wayland-sessions/sway-session.desktop:

[Desktop Entry]Name=Sway ServiceComment=SirCmpwn's Wayland window manager as a systemd serviceExec=sway-service.shType=Application

and put the sway-service.sh somewhere on your PATH (/usr/local/bin/sway-service.sh should be fine):

#! /bin/sh# first import environment variables from the login managersystemctl --user import-environment# then start the serviceexec systemctl --wait --user start sway.service

Next time you login via gdm/sddm just choose "sway-service", instead of just "sway".

Create the file/etc/systemd/user/sway.service:

[Unit]Description=sway - SirCmpwn's Wayland window managerDocumentation=man:sway(5)BindsTo=default.targetWants=default.targetAfter=default.target[Install]WantedBy=default.target[Service]Type=simpleEnvironmentFile=-%h/.config/sway/envExecStart=/usr/bin/swayRestart=on-failureRestartSec=1TimeoutStopSec=10

Then enable the systemd service:systemctl --user enable sway.service && systemctl --user daemon-reload. Sway will start after nexttty login.

Starts Waybar as part of the sway session and stops it whengraphical-session.target stops:

# ~/.config/systemd/user/waybar.service or /etc/systemd/user/waybar.service[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=simpleExecStart=/usr/bin/waybar[Install]WantedBy=sway-session.target

Enable and start the service withsystemctl --user enable --now waybar.

If you want Waybar to start for any graphical session, you could replace theWantedBy= directive withWantedBy=graphical-session.target before enabling it (although it might not make sense to use Waybar with gnome or i3).

[Unit]Description=Idle manager for WaylandDocumentation=man:swayidle(1)PartOf=graphical-session.target[Service]Type=simpleExecStart=/usr/bin/swayidle -w \            timeout 300'swaylock -f -c 000000' \            timeout 600'swaymsg "output * dpms off"' \                resume'swaymsg "output * dpms on"' \            before-sleep'swaylock -f -c 000000'[Install]WantedBy=sway-session.target

Use case: You want to abide by upcomingenvironment.d way of managing your environment variables

Anti use-case: You don't find a good enough reason to abide byenvironment.d's way.

Handily enough, theenvironment.d's generator returns plainKEY=VALUE pairs, which we can eval-export line by line. You can put something around those lines in your sway startup wrapper script.

Sure enough: when attempting to start sway viasystemd, you might use a systemd-recommended method to set this environment, instead.

#!/bin/bash...# Environmentwhileread -r l;doevalexport$ldone<<(/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator)...

• sway-systemd Provides systemd integration for Sway but does not run Sway itself as a systemd service
• sway-services Runs sway itself as a systemd service and provides some other systemd integration
• uwsm Universal Wayland Session Manager that wraps sway (or other compositors) into systemd units. Supports XDG autostart, environment management, extendable with plugins.

See#5160.