[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.
Roger
__________________________________________________________________________
Introduction
------------
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
# 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
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
/etc/passwd.
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
https://lists.alioth.debian.org/pipermail/nut-upsuser/2017-June/010729.html
[2] For a discussion of how to send notifications to all running X-server
users, see
https://unix.stackexchange.com/questions/2881/show-a-notification-across-all-running-x-displays
[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