Sorry for the delay, On 03/03, Norbert Preining wrote: > Is there a way to claim that interface/service somehow? I am thinking of > other cinnamon users (since I am one of the maintainers of Cinnamon in > Debian), and how Cinnamon could stop dbus from starting another > notification daemon, when the one from cinnamon is already running. > Is there a way for this?
That's already the case, dunst cannot start if another notification daemon is running, you can test it by running dunst and trying to start a second instance of it: ``` $ dunst BadAccess (attempt to access private resource denied) BadAccess (attempt to access private resource denied) Unable to grab key "ctrl+grave" Cannot acquire 'org.freedesktop.Notifications': Name is acquired by PID '1547'. ``` So sadly it's either a race over which daemon gets the address first, or up to dbus to decide which daemon to start. > Or is it anyway too late, because the notification service is started > already before the cinnamon session is started? (during xsession > somewhere)? Unless there are user modifications to the startup scripts dunst is only started by dbus. So if the systemd service is disabled it shouldn't be running at all until a notification comes in and dbus starts it. > Not really anything better than learning how to claim the dbus faster > than dunst? > Is there a way to "shadow"/disable it, similar to shadowing of systemd > units? I'm not aware of anything else, some googling brought me to this bug[1]: > The recommended way to disable a D-Bus service is currently "don't install > it". Another comment in that bug suggests that you could override the service file from `~/.local/share/dbus-1/services` and neutralize it that way, but I'm not sure whether that'll work. [1] https://gitlab.freedesktop.org/dbus/dbus/issues/70
