The program ``wall´´ used by NUT to put notifications in front of the users is now well past it's best-before date. It has not been internationalized, does not support accented letters or non-latin characters, and is ignored by popular desktop environments such as Gnome and KDE. It's apparent replacement, notify-send, gives the impression that it has never been tested in any other than the simplest cases, and that it is not ready for industrial strength use. Getting notify-send to work with NUT is not evident: this note discusses the problem.



The program notify-send is part of a set of programs which implement the Gnome ``Desktop Notifications Specification´´ [3].

The introduction says:

<< This is a draft standard for a desktop notifications service, through
  which applications can generate passive popups to notify the user in an
  asynchronous manner of events. ...  Example use cases include:

 * Scheduled alarm
 * Low disk space/battery warnings ... >>

From this introduction it would seem that desktop notifications are
exactly what is needed to present [OL]->[OB] and [OB]->[OB LB] warnings to the users, but unfortunately, things are not that simple.

Program notify-send is a utility which feeds message objects to a message server, such as notifyd. As an example, the Xfce desktop environment provides it's message server called xfce4-notifyd. None of these programs has a man page and I have not been able to find a mailing list specific to desktop notifications.

Experience shows that just calling notify-send in the script upssched-cmd does not work. The message simply disappears. Closer examination with command ps -elf | grep ups shows that if daemon upsmon running as user ``upsd´´ calls notify-send to present a message, the notify daemon is launched with the same userid ``upsd´´ as the caller.

If the caller is the upsmon daemon which has no access to the desktop environment, then neither will the corresponding notification daemon. This is surprising. One would expect a design closer to that of the printer daemon cupsd which runs permanently in the background receiving files to be printed. There is only one daemon cupsd and that daemon isolates the user from needing to know how to drive printers.

To get the message to show on the user's screen appears to require three actions:

 1. Give user ``upsd´´ access to the local X-server,
 2. Make user ``upsd´´ a regular user,
 3. Define environment variable DISPLAY in upssched-cmd.

Give user ``upsd´´ access to the X-server

In NUT, ``upsd´´ is not a regular user and does not have the access to the X-server needed to display data. This is a problem for the notification service, which we now fix.

Add the script

   # Give user upsd access to X-server for notify-send display
   xhost +si:localuser:upsd

to directory /etc/X11/xinit/xinitrc.d. This address works with openSUSE and probably with Fedora and RedHat. It will probably be different in Debian and Ubuntu.

When X starts next time, this new script will be sourced from the script /etc/X11/xinit/xinitrc-common. It adds the user ``upsd´´ to the list of users authorised to access the local X-server. See man xhost. Verify that ``upsd´´ has been added with the command xhost (no options specified).

Make user ``upsd´´ a regular user

Whilst it is necessary to give user ``upsd´´ access to the X-server, my experience is that more is needed to get the notification in front of the users.

User ``upsd´´ needs to be turned into a regular user. Without changing the user id or the group id:

 1. Make the password usable and unlocked.
 2. Make the default shell usable, for example /bin/bash.
 3. Define a home directory for ``upsd´´ and set the directory in

Define environment variable DISPLAY

The upsmon daemon which calls the script upssched-cmd is itself called as a background task without console or desktop environment access. The environment variable DISPLAY is not defined when the script upssched-cmd is executed. However notify-send and it's notification daemon need the address of the X-server, so we prefix the calls to notify-send

   DISPLAY=":0.0" notify-send -a nut -t 0 -u critical "NUT" "$MSG"

Testing the notify-send setup

A simple way of testing the use of notify-send if you are using a configuration which includes the script upssched-cmd is to simply disconnect the wall power for 10 seconds. This is sufficient to provoke upsmon into calling upssched-cmd which in turn calls notify-send.

While wall power is disconnected, use a command such as
   ps -elf | grep -E "ups[dms]|nut"
to find the programs running as user ``upsd´´:

   upsd  2635     1  ... /usr/bin/usbhid-ups -a Eaton
   upsd  2637     1  ... /usr/bin/dummy-ups -a heartbeat
   upsd  2641     1  ... /usr/sbin/upsd
   root  2645     1  ... /usr/sbin/upsmon
   upsd  2646  2645  ... /usr/sbin/upsmon
   upsd  3217     1  ... /usr/sbin/upssched UPS Eaton@localhost: On battery
   upsd  3236     1  ... dbus-launch --autolaunch=d1cd...ca5d2 ...
   upsd  3237     1  ... /bin/dbus-daemon --fork --print-pid 5 ...
   upsd  3241     1  ... /usr/lib/xfce4/notifyd/xfce4-notifyd
   upsd  3243     1  ... /usr/lib/xfce4/xfconf/xfconfd

Thje last 4 lines are due to the use of notify-send. Note that the xfce4-notifyd daemon is running as user ``upsd´´!

References for notify-send

[1] For a suggestion of how to send notifications on an Apple Mac, see

[2] For a discussion of how to send notifications to all running X-server users, see

[3] The Gnome ``Desktop Notifications Specification´´ is still a very long way from being RFC quality.
Nut-upsuser mailing list

Reply via email to