If you use a Wayland compositor like Sway or Hyprland, mako is a great lightweight notification daemon. Many distros make it “start automatically” via a systemd user service, so you don’t need to add exec mako to your compositor config.
I’m experimenting with a setup with KDE, Sway, and Hyprland installed on the same machine and used by the same user, and there’s a catch: KDE on Wayland is also a Wayland session, so the same auto-start logic can kick in there too — and you end up with mako running in Plasma when you don’t want it.
This post shows a clean fix: keep mako auto-starting in Sway/Hyprland, but skip it in KDE, using a systemd drop-in override that lives nicely in your dotfiles (e.g., with chezmoi).
Why mako starts in KDE
On many systems, the provided user unit checks only whether you’re in a Wayland session:
|
1 2 |
ExecCondition=/bin/sh -c [ -n "$WAYLAND_DISPLAY" ] |
KDE Wayland sets WAYLAND_DISPLAY too, so mako passes the check and runs.
The fix: restrict the systemd unit to Sway/Hyprland
Create a systemd user drop-in:
|
1 2 |
systemctl --user edit mako.service |
This opens an editor and writes a file under:
~/.config/systemd/user/mako.service.d/override.conf
Put this in that file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
[Unit] PartOf=graphical-session.target After=graphical-session.target [Service] # Replace the distro's generic Wayland check (true in KDE Wayland too) ExecCondition= # Start only in Sway or Hyprland ExecCondition=/bin/sh -c '\ [ -n "$SWAYSOCK" ] || \ [ -n "$HYPRLAND_INSTANCE_SIGNATURE" ] || \ [ "$XDG_CURRENT_DESKTOP" = "sway" ] || \ [ "$XDG_CURRENT_DESKTOP" = "Hyprland" ]' |
Apply it:
|
1 2 3 |
systemctl --user daemon-reload systemctl --user restart mako.service |
Now mako should start in Sway/Hyprland, and be skipped in KDE.
Verify what systemd is using
To see the merged unit (vendor file + your override):
|
1 2 |
systemctl --user cat mako.service |
To confirm whether it’s running and why:
|
1 2 |
systemctl --user status mako.service |
If you log into KDE and it’s skipped, you’ll typically see a reason related to the ExecCondition.
Making it portable with chezmoi
Since systemctl --user edit produces a file in your home directory, it’s perfect for dotfiles.
With chezmoi, just track:
~/.config/systemd/user/mako.service.d/override.conf
On another machine, once mako is installed, that drop-in will be picked up automatically. The only thing to remember is that systemd reads unit changes after a reload (or next login), so if you want it to take effect immediately after chezmoi apply, run:
|
1 2 3 |
systemctl --user daemon-reload systemctl --user try-restart mako.service |
(try-restart is nice because it won’t error if mako isn’t running.)
Bonus note: D-Bus activation
Depending on your distro and setup, mako can also be started via D-Bus when a request for notifications is made. If you find mako still appears in KDE even when the unit is skipped, check whether it’s being D-Bus activated — and then either:
– rely on a KDE-native notification daemon in Plasma, or
– mask the D-Bus service for org.freedesktop.Notifications for KDE sessions only.
(Usually, the systemd drop-in above is enough.)