Bug#1151954: notification-daemon: register itself as a D-Bus service for on-demand activation

[Simon McVittie]

Control: tags -1 + wontfix

On Sun, 25 Oct 2026 at 08:02:50 +0000, CarlesPina wrote:
>carles at 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 at 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