← All solutions
Caelestia Shell · Notifications

Dunst hijacking the notification D-Bus

Caelestia Shell has its own built-in notification daemon. If Dunst is installed and running, it registers on D-Bus first and intercepts every notification, bypassing Caelestia's system entirely - resulting in plain grey popups instead of the shell's styled top-corner toasts.

Arch Linux Hyprland + Caelestia Shell Quickshell / QML
Symptom

Running notify-send "Test" "Hello" shows a plain grey/white popup in the center of the screen, completely ignoring Caelestia Shell's notification style and position (top-right corner).

The popup has no rounded corners, no blur, no color theming - it looks nothing like the rest of the Caelestia interface.

Root Cause

Caelestia Shell already has a built-in notification daemon implemented in Quickshell/QML. It registers on the org.freedesktop.Notifications D-Bus interface to receive and render notifications in its own style.

The problem: Dunst was also installed on the system. Since Dunst is a system service that starts automatically, it registers on that same D-Bus name before Caelestia Shell finishes loading. D-Bus only allows one owner per name - whichever process registers first wins. Dunst wins, Caelestia never gets the notifications.

Dunst is often installed as an optional dependency of other packages (media players, launchers, etc.). You may not have installed it deliberately - it likely came along silently.
Fix

Mask Dunst's systemd unit so it can never start automatically, then kill the running instance.

bash
# Mask the service so it never auto-starts again
systemctl --user mask dunst.service

# Kill the currently running instance
killall dunst

No restart needed. Caelestia Shell reclaims the D-Bus name immediately and your notifications will now appear in the correct style and position.

bash - verify it worked
notify-send "Test" "Caelestia is handling this"
# Should now appear in the top-right corner with Caelestia's style
If you install any package that lists dunst as an optional dependency, check that it hasn't unmasked the service:

systemctl --user is-enabled dunst.service

It should return masked. If it shows enabled or disabled, run systemctl --user mask dunst.service again.