Update Example-systemd-Setup.md to use add-wants (#1710)

Instead of hard-linked locations tried to reword to simplify for both XDG-compliance and/or non-compliance. Additionally, replace 'ln ...' references with "add-wants" from systemctl. This advantage is that it creates all the right directories and the only thing the user needs to worry about later is possibly removing a symlink manually.
This commit is contained in:
Nathan
2025-06-11 01:18:26 -05:00
committed by GitHub
parent 8d7b22d1a8
commit 7db864d203
+17 -16
View File
@@ -2,24 +2,21 @@ When starting niri from a display manager like GDM, or otherwise through the `ni
This provides the necessary systemd integration to run programs like `mako` and services like `xdg-desktop-portal` bound to the graphical session. This provides the necessary systemd integration to run programs like `mako` and services like `xdg-desktop-portal` bound to the graphical session.
Here's an example on how you might set up [`mako`](https://github.com/emersion/mako), [`waybar`](https://github.com/Alexays/Waybar), [`swaybg`](https://github.com/swaywm/swaybg) and [`swayidle`](https://github.com/swaywm/swayidle) to run as systemd services with niri. Here's an example on how you might set up [`mako`](https://github.com/emersion/mako), [`waybar`](https://github.com/Alexays/Waybar), [`swaybg`](https://github.com/swaywm/swaybg) and [`swayidle`](https://github.com/swaywm/swayidle) to run as systemd services with niri.
In contrast to [`spawn-at-startup`](./Configuration:-Miscellaneous.md#spawn-at-startup), this lets you easily monitor their status and output, and restart or reload them. Unlike [`spawn-at-startup`](./Configuration:-Miscellaneous.md#spawn-at-startup), this lets you easily monitor their status and output, and restart or reload them.
1. Install them, i.e. `sudo dnf install mako waybar swaybg swayidle` 1. Install them, i.e. `sudo dnf install mako waybar swaybg swayidle`
2. Create a `niri.service.wants` folder: `mkdir -p ~/.config/systemd/user/niri.service.wants` 2. `mako` and `waybar` provide systemd units out of the box, so you can simply add them to the niri session:
This is a special systemd folder.
Any services linked there will be started together with `niri.service` (which is a systemd unit used by niri when running as a session).
3. `mako` and `waybar` provide systemd units out of the box, so you can simply symlink them into the `niri.service.wants` folder:
``` ```
ln -s /usr/lib/systemd/user/mako.service ~/.config/systemd/user/niri.service.wants/ systemctl --user add-wants niri.service mako.service
ln -s /usr/lib/systemd/user/waybar.service ~/.config/systemd/user/niri.service.wants/ systemctl --user add-wants niri.service waybar.service
``` ```
4. `swaybg` does not provide a systemd unit, since you need to pass the background image as a command-line argument. This will create links in `~/.config/systemd/user/niri.service.wants/`, a special systemd folder for services that need to start together with `niri.service`.
3. `swaybg` does not provide a systemd unit, since you need to pass the background image as a command-line argument.
So we will make our own. So we will make our own.
Put the following into `~/.config/systemd/user/swaybg.service`: Create `~/.config/systemd/user/swaybg.service` with the following contents:
``` ```
[Unit] [Unit]
@@ -37,13 +34,14 @@ In contrast to [`spawn-at-startup`](./Configuration:-Miscellaneous.md#spawn-at-s
After editing `swaybg.service`, run `systemctl --user daemon-reload` so systemd picks up the changes in the file. After editing `swaybg.service`, run `systemctl --user daemon-reload` so systemd picks up the changes in the file.
Now, also symlink this to `niri.service.wants`: Now, add it to the niri session:
``` ```
ln -s ~/.config/systemd/user/swaybg.service ~/.config/systemd/user/niri.service.wants/ systemctl --user add-wants niri.service swaybg.service
``` ```
5. `swayidle` similarly does not provide a service so we will also make our own. Put the following into `~/.config/systemd/user/swayidle.service`: 4. `swayidle` similarly does not provide a service, so we will also make our own.
Create `~/.config/systemd/user/swayidle.service` with the following contents:
``` ```
[Unit] [Unit]
@@ -56,16 +54,19 @@ In contrast to [`spawn-at-startup`](./Configuration:-Miscellaneous.md#spawn-at-s
Restart=on-failure Restart=on-failure
``` ```
Then, run `systemctl --user daemon-reload` and symlink this file to `niri.service.wants`: Then, run `systemctl --user daemon-reload` and add it to the niri session:
``` ```
ln -s ~/.config/systemd/user/swayidle.service ~/.config/systemd/user/niri.service.wants/ systemctl --user add-wants niri.service swayidle.service
``` ```
That's it! That's it!
Now these three utilities will be started together with the niri session and stopped when it exits. Now these three utilities will be started together with the niri session and stopped when it exits.
You can also restart them with a command like `systemctl --user restart waybar.service`, for example after editing their config files. You can also restart them with a command like `systemctl --user restart waybar.service`, for example after editing their config files.
To remove a service from niri startup, remove its symbolic link from `~/.config/systemd/user/niri.service.wants/`.
Then, run `systemctl --user daemon-reload`.
### Running Programs Across Logout ### Running Programs Across Logout
When running niri as a session, exiting it (logging out) will kill all programs that you've started within. However, sometimes you want a program, like `tmux`, `dtach` or similar, to persist in this case. To do this, run it in a transient systemd scope: When running niri as a session, exiting it (logging out) will kill all programs that you've started within. However, sometimes you want a program, like `tmux`, `dtach` or similar, to persist in this case. To do this, run it in a transient systemd scope: