[Nut-upsuser] On getting notify-send to work

Roger Price roger at rogerprice.org
Thu Aug 17 19:54:35 UTC 2017

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 

  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

    # localuser.sh
    # 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 

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 

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 at 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. https://developer.gnome.org/notification-spec/

More information about the Nut-upsuser mailing list