Dunst: a notification daemon you configure by hand

What Dunst replaces on a bare desktop

Desktop environments ship their own notification popups. If you run a window manager without one, applications that call the freedesktop notification interface have nowhere to send their messages. Dunst is the process that answers those calls. It is a daemon written in C, and its stated job in the README is to be "a highly configurable and lightweight notification daemon." The topics attached to the repository list dbus, libnotify, notification-daemon, wayland and x11, which describes the layers it sits between: applications speak D-Bus, Dunst receives, and Dunst paints on whichever display server you built it for.

The audience is narrow and specific. Someone running i3, sway or Hyprland needs a notification daemon the same way they need a status bar, and they usually want it to match a theme they assembled themselves rather than accept a vendor default. Dunst assumes that person is comfortable editing a text file. The README's customization section says fonts, icons and timeouts can all be changed "with a simple configuration file tweak," and links screenshots to the dunstrc files that produced them. That is the pitch: the configuration is the product.

Rules, scripts and pause levels as the real feature set

The interesting part of Dunst is not that it draws a box. It is the matching layer on top. Rules let you change the look or behaviour of notifications that match a pattern. The README gives two examples: recolouring messages from a particular contact, and preventing work email notifications from disappearing until you dismiss them manually. That second case is the one that matters in practice, because it turns a transient popup into something closer to a queue.

Scripting extends the same matching idea to external programs. The README describes running custom scripts on notifications matching a pattern, with espeak reading notifications aloud or a song playing when a contact signs on. Both features read from the same configuration surface, so the mental model is one file with match blocks that branch into appearance, timeout and side effects.

Pause is the third mechanism and the one with a subtle design. Pausing stops notifications from being shown, and the README states that all notifications are saved for you to catch up later. There is also a numeric pause level, which pauses selectively: more urgent notifications get through while less urgent ones stay paused. That is a real distinction from a simple on/off toggle, and it means urgency has to be set meaningfully by the sending application for the feature to be useful. History is the companion: a keyboard shortcut replays the last notification, and tapping again walks back through the history.

Installing Dunst and sending a first notification

The README says Dunst is available in many package repositories, so the first thing to try is your distribution's package manager. If it is not packaged, the repository documents two build paths. The Makefile path clones and installs:

git clone https://github.com/dunst-project/dunst.git
cd dunst
make
sudo make install

The Meson path does the same work with a separate build directory:

meson setup build
ninja -C build
ninja -C build install

Two constraints come from the Makefile and are worth reading before you start. The first is that the build needs at least one output backend: the Makefile errors with "You have to compile at least one output (X11, Wayland)" when both X11 and WAYLAND are set to 0. The second is that all make invocations must use the same parameter set, so a build with make PREFIX=/usr has to be installed with make PREFIX=/usr install. The README states this in bold terms, and it is the most common way a hand-built install ends up split across two prefixes.

Dependencies are listed by pkg-config name rather than by distribution package: gdk-pixbuf-2.0, glib-2.0, gio-2.0 and pangocairo are required, while libnotify, wayland-client, wayland-cursor and the X11 libraries are optional depending on which features you enable. The README notes the names differ per distribution and points to the wiki for the mapping. Once running, the daemon listens on the D-Bus notification interface, so any application using libnotify will reach it. The repository also ships dunstify, a libnotify-based utility controlled by the DUNSTIFY build flag, which is the natural way to send a test notification without waiting for a real application to fire one.

Configuration is a text file, and that is the whole interface

There is no settings dialog. The README points configuration questions at dunst(5), the man page that documents every option, and at the wiki and website FAQ for guides and common issues. The repository root contains a dunstrc file, which is the default configuration installed to SYSCONFFILE, defaulting to ${SYSCONFDIR}/dunst/dunstrc under ${PREFIX}/etc/xdg.

One detail in the README deserves attention because it surprises people who set XDG variables: Dunst uses a different default for XDG_CONFIG_DIRS at runtime than the usual one, namely ${SYSCONFDIR}. The README raises this explicitly. If your setup depends on XDG_CONFIG_DIRS pointing somewhere else, the config lookup may not follow it the way other applications do.

The install behaviour of the default file is also deliberate. SYSCONF_FORCE_NEW defaults to 0, meaning an existing ${SYSCONFFILE} is not overwritten, and the Makefile computes the default by testing whether that file exists. Upgrades therefore do not clobber a system-wide dunstrc you edited. Your personal configuration is separate, and the README's screenshots link to real dunstrc files as examples, which is more useful than a list of option names when you are trying to reproduce a look.

Where Dunst is the wrong tool

Dunst draws its own notifications and expects to be the notification daemon. If your desktop environment already runs one, starting Dunst means two processes competing for the same D-Bus name, and only one will win. That is not a bug to report; it is the architecture. On a full GNOME or KDE session, the built-in notification system is integrated with the shell in ways Dunst cannot replicate, and replacing it is usually a downgrade unless you specifically dislike the default.

The second limitation is documentation shape. The README directs you to man pages, a wiki and a website FAQ. There is no interactive configurator and no validation tool described in the README, so a malformed dunstrc is something you diagnose by reading the man page and restarting the daemon. For someone who wants to change a timeout once and move on, that is more friction than a settings panel.

Build configuration has its own trap. The Makefile warns that a failed pkg-config query aborts the build, and the Wayland path warns when wayland-protocols cannot be queried. Optional features are compile-time decisions: WAYLAND, X11, DUNSTIFY, COMPLETIONS and SYSTEMD are all Make parameters, so a binary from one distribution may lack a feature another has. If you are debugging behaviour across machines, check how each binary was built before assuming the configuration is at fault.

Dunst against mako, and what the difference actually is

The comparison people search for is Dunst versus mako, a Wayland notification daemon. The architectural difference is visible in this repository's build system. Dunst compiles both an X11 and a Wayland backend, selected by the X11 and WAYLAND Make parameters, and the Makefile requires at least one of them. A single Dunst binary can therefore serve an X11 session or a Wayland session depending on how it was built, and the repository's topics list both x11 and wayland alongside dbus and libnotify.

The configuration difference is larger than the backend difference. Dunst's configuration model is a file with rules that match notification patterns and can trigger scripts, plus pause levels and a replayable history. That is a heavier surface than a minimal popup daemon, and it is the reason to pick Dunst: you want the matching and scripting layer, not just a box in the corner. If you only need notifications displayed and dismissed, the extra configuration surface is cost without benefit.

Neither project is described in this repository's material beyond Dunst itself, so treat the comparison as a question about which configuration model you want to maintain, not about which renders faster. The README makes no performance claim, and none should be inferred from the language choice.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-11. Releases are infrequent and deliberate: v1.13.0 on 2025-08-04, v1.13.1 on 2026-01-23 and v1.13.2 on 2026-03-18. That cadence suits a daemon whose interface is a config file, because there is little pressure to ship. It also means a bug you hit may sit until the next point release, and the repository carries a CHANGELOG.md and a RELEASE_NOTES file as the record of what changed.

Licence is the awkward part. The repository metadata reports NOASSERTION, and the README's copyright section defers to the LICENSE file, with the Makefile header stating "See LICENSE file for copyright and license details." If you plan to redistribute a modified Dunst or ship it inside a product, read LICENSE and AUTHORS directly rather than relying on a package manager's licence tag. This is not legal advice, and the repository metadata alone does not settle the question.

Upgrade cost is mostly configuration drift. The default dunstrc is not overwritten on install because SYSCONF_FORCE_NEW defaults to 0, so a system-wide file can fall behind the options the installed binary understands. Personal configurations are yours to migrate, and the man page is the reference for what changed. Building from source adds the prefix discipline: keep the same parameter set across make and make install, or you will end up with a binary in one place and data files in another.

Editorial conclusion

Dunst suits people who already run a window manager or a minimal desktop and want notification behaviour expressed in a config file they can version. It is the wrong choice if you want a graphical settings panel, since the repository points only to man pages, the wiki and the website FAQ for configuration. Before adopting it, check that your compositor or session actually starts a notification daemon and that no other daemon already owns org.freedesktop.Notifications, then read dunst(5) and decide whether the rules and script hooks cover what you need.

Frequently asked questions

Official sources

1. dunst-project/dunst on GitHub
2. Issues
3. Project website
4. README
5. Releases