Desktop notifications

Related articles
GTK
Libcanberra
Desktop notifications are small, passive popup dialogs that notify the user of particular events in an asynchronous manner.
Libnotify
libnotify
is a desktop-independent implementation of the
Desktop Notifications Specification
, which provides
notify-send(1)
utility and support for
GTK
and
Qt
applications. It is already used by many open source applications like
Evolution
and
Pidgin
.
Tip
An overview on the available icons can be found in the
specification
.
Notification servers
In order to receive notifications sent via
libnotify
, a notification server is required.
Built-in
Cinnamon
,
Deepin
,
Enlightenment
,
GNOME
, and
GNOME Flashback
use their own implementations to display notifications, and may not be able to be replaced since their notification servers are started automatically on login to receive notifications from applications via DBus.
On
KDE Plasma
if you enter the configuration for the System Tray you can disable the built-in notification server under System Services by changing the drop-down next to Notifications to Disabled. You can then add your preferred notification server in the System Settings menu under System / Autostart by adding a new Autostart application. You will need to log out and back in to take effect.
Standalone
In other desktop environments, a notification server needs to be manually installed and launched using e.g.
XDG Autostart
.
Alternatively, by making the notification server a
D-Bus
service, the notification server can be launched automatically on the first call to it. Most notification servers already ship a dbus service under
/usr/share/dbus-1/services
. For some implementations, e.g.
notification-daemon
package, it's necessary to create one manually in the user
D-Bus
services directory (
$XDG_DATA_HOME/dbus-1/services
):
org.freedesktop.Notifications.service
[D-BUS Service]
Name=org.freedesktop.Notifications
Exec=/usr/lib/notification-daemon-1.0/notification-daemon
Whenever an application sends a notification by sending a signal to
org.freedesktop.Notifications
, D-Bus activates
/usr/lib/notification-daemon-1.0/notification-daemon
if it has not already been activated.
You can also choose one of the following implementations:
Deadd Notification Center
— A notification-daemon with notification center inspired by Dunst. -
not under active development any more as of February 2025
https://github.com/phuhl/linux_notification_center
||
deadd-notification-center
AUR
Dunst
— Minimalist notification daemon for Linux designed to fit nicely into minimalist window managers like
dwm
. Includes Wayland support since 1.6.
https://dunst-project.org/
||
dunst
fnott
— Keyboard driven and lightweight Wayland notification daemon for wlroots-based compositors.
https://codeberg.org/dnkl/fnott
||
fnott
LXQt Notification Daemon
— Notification server for
LXQt
.
https://github.com/lxde/lxqt-notificationd
||
lxqt-notificationd
mako
— A lightweight notification daemon for
Wayland
; it currently works on
Sway
,
Hyprland
and
river-classic
.
https://github.com/emersion/mako
||
mako
MATE Notification Daemon
— Notification server for
MATE
.
https://github.com/mate-desktop/mate-notification-daemon/
||
mate-notification-daemon
Notification Daemon
— The original notification server.
https://gitlab.gnome.org/Archive/notification-daemon
||
notification-daemon
You can run it manually using
/usr/lib/notification-daemon-1.0/notification-daemon
.
Notify OSD
— Notification server for Unity.
https://launchpad.net/notify-osd
||
notify-osd
statnot
— Small, lightweight notification daemon that can output notifications to the root window's title, stdout or FIFO pipes, making it integrate very well with tiling window managers.
https://github.com/halhen/statnot
||
statnot
AUR
swaync
— A simple GTK based notification daemon for
Sway
.
https://github.com/ErikReider/SwayNotificationCenter
||
swaync
twmn
— Notification system for tiling window managers.
https://github.com/sboli/twmn
||
twmn-git
AUR
UKUI Notification Daemon
—
https://github.com/ukui/ukui-notification-daemon
ukui-notification-daemon
AUR
||
not packaged?
search in AUR
wired
— Lightweight notification daemon with highly customizable layout blocks, written in Rust.
https://github.com/Toqozz/wired-notify
||
wired
AUR
Xfce Notification Daemon
— Notification server for
Xfce
.
https://docs.xfce.org/apps/notifyd/start
||
xfce4-notifyd
You can run it manually using
/usr/lib/xfce4/notifyd/xfce4-notifyd
.
Tip
To configure xfce4-notifyd, run the following command:
xfce4-notifyd-config
.
Tips and tricks
Send notifications to another user
systemd-run(1)
can be used to enter another user's session and send notifications to them, e.g. from a background script running as root:
# systemd-run --machine=
target_user
@.host --user notify-send 'Hello world!' 'This is an example notification.'
Send notifications to all graphical users
This can be extended to send a notification to all graphical users with the following:
# for id in $(loginctl list-sessions -j | jq -r '.[] | .session') ; do
      if [[ $(loginctl show-session $id --property=Type) =~ (wayland|x11) ]] ; then 
          systemd-run --machine=$(loginctl show-session $id --property=Name --value)@.host --user \
          notify-send 'Hello world!' 'This is an example notification.'
      fi
  done
Another possibility is to use
systembus-notify
. The following command will show a notification to all users who run
systembus-notify
in their user session:
$ dbus-send --system / net.nuetzlich.SystemNotifications.Notify 'string:Hello world!' 'string:This is an example notification.'
Tip
You can get notified of failed services by following the instructions at
systemd#Notifying about failed services
and using one of the above commands as the basis of the
ExecStart
command.
Replace previous notification
Notifications can be replaced if their ID is known; if a new notification request specifies the same ID, it will always replace the old notification. Unfortunately notify-send does not report this ID, so alternative tools are required to do this on CLI. One capable CLI-tool is the
notify-send.py
python script, which provides notify-send syntax with additional ID-reporting and replacing capabilities.
However, with
some
notification servers (such as Notify-OSD), you can use the
string:x-canonical-private-synchronous:
hint with notify-send to achieve the same result.
For example, to get a notification displaying time:
while true; do
  date=$(date)
  notify-send "$date" -h string:x-canonical-private-synchronous:my-notification
  sleep 1
done
Include Buttons or listen for close/on-click of the notification
With the
notify-send.py
script, actions can be used to display buttons or to listen for the default-action of the notification (usually, when the user clicks on it) and the close-action. When the
action-icons
hint is set to true and the notification daemon supports this, the buttons will display icons instead of text. The script prints the action identifier or "close" to the command line when the corresponding event has occured. To listen for the default action (on-click), one has to use the action-identifier "default".
Example with icons on buttons:
notify-send.py "Buttons" "Do you like em?" --hint boolean:action-icons:true --action yes:face-cool no:face-sick
Multiple notification servers with D-Bus services
As described in the section
Standalone
, users can create a D-Bus service so that a notification server can be launched automatically. Some implementations already include the D-Bus service files. However, this causes a problem when multiple notification servers are installed and when some of them come with the service files. For example, installing both
dunst
and
mako
without explicitly specifying the desired server, D-Bus then chooses one for the users, and the decision is out of users' control. To avoid the situation, you can override the service used by creating an
org.freedesktop.Notifications.service
(see
#Standalone
) and pointing to the service you want to use, then restarting the session.
Troubleshooting
Applications hanging for exactly one minute
If applications hang when attempting to show notifications, it might be because of a notification service falsely advertising its availability through the D-Bus service.
For instance, suppose a user recently installed a KDE component that requires
plasma-workspace
, but the user is still running XFCE. In this case, the KDE notifier will be prioritized, but the user is not running it. The application will hang while waiting for the service, and only after a timeout will it fall back to
xfce4-notifyd
.
The most noticeable hanging might come from the volume indicator scroll adjustment.
If you are in this situation, you should have two notification handlers:
$ find /usr/share/dbus-1/services/ -name '*Notif*'
org.kde.plasma.Notifications.service
org.xfce.xfce4-notifyd.Notifications.service
Of those two, one fails regularly after a 1-minute timeout, as seen in the
journal
:
# journalctl -g notif
Jul 01 09:40:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activating service name='org.freedesktop.Notifications' requested by ':1.193' (uid=1000 pid=5432 comm="/usr/lib/xfce4/panel/wrapper-2.0 /usr/lib/xfce4/pa")
Jul 01 09:41:49 laptop plasma_waitforname[6093]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Jul 01 09:41:49 laptop dbus-daemon[866]: [session uid=1000 pid=866] Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
Choosing the service you want to use as described in
#Multiple notification servers with D-Bus services
will fix the problem.
See also
Libnotify Reference Manual
C example
(archived version)
Python notification examples
Python notify example
(french article)