Control: tags -1 + wontfix
On Sun, 25 Oct 2026 at 08:02:50 +0000, CarlesPina wrote:
carles@debian:~$ notify-send "test"
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Notifications was not provided by any .service files
This is intentional: there used to be a D-Bus .service file for
notification-daemon, but it was removed in
<https://gitlab.gnome.org/Archive/notification-daemon/-/commit/1ad20d22098bc7718614a8a87744a2c22d5438d0>
because automatic activation was breaking gnome-shell (and, with
hindsight, it was the wrong thing to do anyway).
The D-Bus session bus does not have a good way to choose one of several
implementations of the same well-known name: if more than one package
installs a .service file for the same well-known name, on the first
activation request one of them will be chosen, non-deterministically (I
think it depends on readdir() order).
On the system bus, only the .service file whose name matches the
well-known name is allowed to provide an activatable service (for
example the only way to make the name org.bluez activatable is to
provide a file named org.bluez.service). This means that multiple
implementations of the same activatable service would have to cooperate
and use either Conflicts/Replaces or /etc/alternatives. The session bus
can't do this because that would be a backward-compatibility break, but
one thing I've considered in the past is making the session bus prefer
to use the matching filename if multiple implementations exist.
D-Bus service activation is great for situations where there is only one
implementation of a service (like NetworkManager or BlueZ), or where
there can only be one implementation of a service per machine (like
systemd-logind and elogind as mutually-exclusive providers of the
org.freedesktop.login1 name), but it isn't the right tool for situations
where each desktop environment will want a different implementation for
the same bus name.
If a service needs to have multiple backends for different desktop
environments, then a much more complicated implementation is necessary,
for example xdg-desktop-portal and its
/usr/share/xdg-desktop-portal/*.conf files, or starting services eagerly
via autostart .desktop files instead of relying on on-demand activation.
In a Debian trixie installation with task-lxde-desktop: it does install
notification-daemon but by default it does not register itself to d-bus
for on-demand activation.
If LXDE wants to use notification-daemon (or dunst or any other specific
implementation) as its implementation of org.freedesktop.Notifications,
then it should start the service during login, either via an autostart
.desktop file or by running it directly. This is the sort of interface
that desktop environments in the 2020s are expected to provide. The
major desktop environments do have an integrated Notifications
implementation, either built-in to the desktop shell (like GNOME Shell),
or starting a separate implementation via an autostart .desktop file
(like LXQt's lxqt-notificationd), or starting a separate implementation
in some other way (for example, in the past, GNOME Flashback started
notification-daemon as a gnome-session service).
Because notification-daemon is unmaintained upstream, I think it should
be removed from Debian, either before Debian 14 or during the Debian 15
cycle, which would force each desktop environment to choose a maintained
alternative and take responsibility for starting it.
I see that dunst has some files to register itself as a notification
provider:
carles@pinux:~$ cat /usr/share/dbus-1/services/org.knopwob.dunst.service
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/bin/dunst
SystemdService=dunst.service
This scales very poorly. If you have dunst and some other implementation
of the notifications interface that is behaving like dunst, then the
dbus-daemon will choose one of them, non-deterministically.
smcv
