Dunst: How to disable dunst in Unity

[Maxlufs]

How can I disable dunst as the default notification daemon in Unity?

After installing i3wm and switched back to dunst, dunst is taking charge over notify osd. The solution online was to purge dunst at all. Is there any other configuration that I could use dunst in i3 while keep notify osd in Unity?

Thanks!

[tsipinakis]

Sorry for the delay, as mentioned in another comment I wasn't home for the past few days.

Dunst (and probably notify-osd) are started automatically via a dbus service usually located in /usr/share/dbus-1/services/ (dunsts service for example is org.knopbox.dunst.service).

if you remove these files the notification daemon will not be started automatically when a notification comes through meaning that you'll have to start it yourself at every session (and restart when it crashes).

[tsipinakis]

@Maxlufs Was your question resolved? If so you should close the issue.

[bebehei]

@tsipinakis This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution. It's against every principle of Unix. But I can't say that solution is wrong, it's currently the best.

If you close this issue, there should be at least a FAQ/wiki entry about a good the solution. Others will have this problem later, too. In other projects I had a similar type of issue, opened a bugreport, but it got closed again as a duplicate of another bug. This is contraproductive. The maintainer is pissed, I've created work and others will also tap into this trap. We should have a note somewhere at least.

I did some research today about conflicting DBUS Busses, but I could not find anything. I will join the dbus IRC this evening and search ask those guys. Maybe someone of the pros has better understanding.

[WhyNotHugo]

This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution.

Well, you want to install an application, but avoid other applications from discovering it, I don't think there's a really clean solution.

As an alternative though; if you manually start notify-osd, does dunst still get auto-started when sending a notification?

[tsipinakis]

This is a common problem and IMHO the solution "remove the file manually from /usr" is not a good solution.

As you said, while I also don't like the solution there is no workaround currently and it's not an issue dunst can fix - this is up to dbus.

As an alternative though; if you manually start notify-osd, does dunst still get auto-started when sending a notification?

I'd assume no here since there's already an application on that address so dbus doesn't attempt the activation of another one. The real question is how dbus decides which one to launch if both use the same address.

[bebehei]

Finally:

There is no clean possibility to have different notification-managers on a per-session basis. To switch automatically per session, you would have to write an (easy) script, which starts based on its env (or the surrounding processes) the notification-daemon manually.

But, there is a quite easy solution on a per user basis. This is simply everything to do:

# use dunst
SERVICE=org.knobwob.dunst
# use default
SERVICE=
mkdir -p "${XDG_DATA_HOME:-~/.local/share}/dbus-1/services"
ln -sT \
    "/usr/share/dbus-1/services/${SERVICE:-org.Freedesktop.Notifications}.service" \
    "${XDG_DATA_HOME:~/.local/share}/dbus-1/services/org.freedesktop.Notifications.service"

It looks quite complex, but it actually just links the service-file into the user's home-directory, where dbus uses these files with higher precedence. Depending on the content of the SERVICE variable, it either uses the default or dunst (or any other configuration, you put in there.

I think we should document this somewhere in the FAQ/somewhere else. If I figure out, how the dunst-project.org repo is organized, I'll fire a PR against it. Edit: mhmmm. There is no FAQ on the website!?

---

The real question is how dbus decides which one to launch if both use the same address.

• There is standard_session_servicedirs, which is a PATH option, containing multiple folders, searched for .service-files. If two files containing the same Name=ghi.def.abc, then the file in the first directory will be taken. As the PATH-option is structured $XDG_DATA_HOME/dbus-1/services:[...]:${datadir}/dbus-1/services[0], you can always overwrite as a user the default services in your home.
• If two files containing the same Name=ghi.def.abc are in the same directory, the selection is arbitary. So non-deterministic. Even if one of the files is called ghi.def.abc.service, there is no real precedence.

So there is at least a solution, which does not touch /usr and does this also on a per-user-basis.

[0] XDG_DATA_HOME defaults to ~/.local/share and datadir to /usr/share/

[WhyNotHugo]

@bebehei Thanks for that thorough explanation.

[tsipinakis]

I think we should document this somewhere in the FAQ/somewhere else. If I figure out, how the dunst-project.org repo is organized, I'll fire a PR against it. Edit: mhmmm. There is no FAQ on the website!?

I've been meaning to do some work on the website for a while now, especially adding some more documentation on there, but it'll have to wait until I get some more free time. In the meantime feel free to send a PR if you want to work on this, otherwise there's a FAQ on the github wiki free for everyone to edit.

[bebehei]

So, I ported the FAQ-stuff to the website and added the explanation to this issue: Fixed in dunst-project/dunst-project.org#2

[bebehei]

@tsipinakis after dunst-project/dunst-project.org#2 got merged, what about closing this here?