Desktop notifications
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.
Notification servers
In order to receive notifications sent via libnotify, a notification server is required.
Built-in
Cinnamon, Deepin, Enlightenment, GNOME, GNOME Flashback and KDE Plasma use their own implementations to display notifications, and it cannot be replaced. Their notification servers are started automatically on login to receive notifications from applications via DBus.
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.
- Dunst — Minimalist notification daemon for Linux designed to fit nicely into minimalist window managers like dwm. Includes Wayland support since 1.6.
- fnott — Keyboard driven and lightweight Wayland notification daemon for wlroots-based compositors.
- LXQt Notification Daemon — Notification server for LXQt.
- MATE Notification Daemon — Notification server for MATE.
- 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.
- 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.
- swaync — A simple GTK based notification daemon for Sway.
- twmn — Notification system for tiling window managers.
- wired — Lightweight notification daemon with highly customizable layout blocks, written in Rust.
- 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.'
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-identfier "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 a org.freedesktop.Notifications.service (see #Standalone) and pointing to the service you want to use, then restarting the session.
Notifications on failed Systemd services
To get notified by failed services, install and run systembus-notify on the target user and follow the instructions given in Systemd#Notifying about failed services, but replace the failure-notification@ template unit with this one:
/etc/systemd/system/failure-notification@.service
[Unit] Description=Send a notification about a failed systemd unit After=Graphical.target [Service] Type=simple ExecStart=/usr/bin/dbus-send --system / net.nuetzlich.SystemNotifications.Notify 'string:%i' 'string:Unit failed'
Sadly, this solution does not yet support setting the urgency or timeout of the notifications, see this issue.
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[dead link 2024-07-30 ⓘ]
- C example (archived version)
- Python notification examples
- Python notify example (french article)