Hi,
Running a backup root cron job, that runs a script, to backup stuff across the network.
What I would like to do is, when the script finishes (either successfully or not), to pop up a message in the “standard user” GUI (KDE plasma)
Using
notify-send "Successful data backup"
(or not…)
and if run as the standard user, works fine, but obviously, when run using root cron - no message…
Is it possible to get a message on the standard user desktop?
Thanks.
That is a fundamental problem because you are using a multi-user multi-session system. Thus to begin with at any moment in time there can be 0, 1 or more users running 0, 1 or more sessions of wich 0, 1 or more can be graphical (let us forget that those GUI sessions can use a lot of different desktop sets, saying it is KDE is of course not heard by the system).
Also, when you (as a user) are working in a GUI session, you probably will not be very happy when other users (from other sessions, CLI or GUI) will be able to open windows on your screen, visable or unvisable, key-trackers or different. So that is forbidden by default (even when the user who tries to break into your session is root).
Thus, even if there might be coming “solutions” for your problem, IMHO. it is opening a can of worms.
Thought I might get a reply like that… 
Thanks…
Hi
Why not use email? Anyway, consider switching from cron to systemd and timers/services, perhaps you can do some simple foo to check which users are active (loginctl) and send something or a gui notification;
loginctl list-sessions
You could use “wall” (write to all) to send a message to any user with an open terminal session. Perhaps some desktops will trap this and turn the wall message into a desktop notification.
I’d imagine you can simply send a message to Display:0, maybe Display:1 which ought to display for any currently logged in User no matter who they are and wouldn’t require any special permissions beyond your root.
Something like xmessage described in the following… and just a note, regarding one of the other suggestions to the post using xhost, I avoid that whenever possible because it’s living on the edge whether what you’re doing is secure or not so has been updated within the past few years so many former uses don’t work today
https://superuser.com/questions/309961/linux-how-to-send-message-to-local-user-logged-into-x11
If you really want to identify any logged in Users, I came across this interesting article, “w” might be useful.
https://www.thegeekstuff.com/2009/03/4-ways-to-identify-who-is-logged-in-on-your-linux-system/
TSU
One possibility is to run system-to-user D-Bus bridge as part of user desktop and use standard notifications API. Example implementation is described here (sorry, German, was the first hit): https://wiki.debianforum.de/Desktop-Notification_von_Systemservice_mittels_dbus
‘mail userxyz’ always works unless somebody has tinkered with mail.
That is suggested above, but it is not what the user asked for. I have no idea if it fullfills his whishes (the particular usr(s) must have her/his/their e-mail program running and a not to long time step between checking, etc), but it is certainly one of the easier sulutions (when not the easiest).
To pop up a message window isn’t nice and doing so can have drastic side effects:
It turned out to be an issue with the Linux implementation of tray messages (the java.awt.TrayIcon class). The implementation is simply put **** on Linux and Oracle hasn’t put any efforts into improving it over the years. There are multiple bug reports filed on it (various stuff, not this specific crash). I could get it to work by calling the buggy TrayIcon.displayMessage() call on the JavaFX thread, but only if I was using the Darcula L&F (Look and feel). If I switched to the GTK+ L&F, it hung again. My workaround to this was to simply dump the printing of tray messages on Linux.
Run 2 cron jobs, where the root owned one writes the result to a file, i.e. “Succesful” or “Failed”, a second cron job for the user, that does nothing but read the content of the file and - using whatever can do that - have it send that to the user desired. I’ve had to create something like that for a customer. But … within a month they asked me to remove the “annoying popup”. FWIW, I used zenity for that IIRC.
Hi
I just relay stuff out via google mail as a text message to my phone…
Hey, thanks for all the replies!
Some interesting and helpful thoughts there.
Will have a bit of a think, and test, and see how I go.
John.
You could make your standard user’s graphical session available to root…
user ~$ **xhost +root**
… then, in a script run by root, copy the authorization from the user to root and set your DISPLAY environment variable …
~$ **cp** /home/user/.Xauthority /root/ *# warning: don’t run a graphical session as root simultaneously*
~$ **export** DISPLAY=:0.0* # display ID can vary depending on number of started X seats/sessions*
… finally, use something like kdialog for notifications:
~$ **kdialog** --passivepopup 'hello from root' --title 'root says hi ... using kdialog'
The list of stuff kdialog is capable of is quite interesting:
Usage: kdialog [options] [arg]
KDialog can be used to show nice dialog boxes from shell scripts
Options:
-v, --version Displays version information.
-h, --help Displays this help.
--author Show author information.
--license Show license information.
--desktopfile <file name> The base file name of the desktop entry for
this application.
--yesno <text> Question message box with yes/no buttons
--yesnocancel <text> Question message box with yes/no/cancel
buttons
--warningyesno <text> Warning message box with yes/no buttons
--warningcontinuecancel <text> Warning message box with continue/cancel
buttons
--warningyesnocancel <text> Warning message box with yes/no/cancel
buttons
--yes-label <text> Use text as Yes button label
--no-label <text> Use text as No button label
--cancel-label <text> Use text as Cancel button label
--continue-label <text> Use text as Continue button label
--sorry <text> 'Sorry' message box
--detailedsorry <text> <details> 'Sorry' message box with expandable Details
field
--error <text> 'Error' message box
--detailederror <text> <details> 'Error' message box with expandable Details
field
--msgbox <text> Message Box dialog
--inputbox <text> <init> Input Box dialog
--password <text> Password dialog
--newpassword <text> New Password dialog
--textbox <file> Text Box dialog
--textinputbox <text> <init> Text Input Box dialog
--combobox <text> ComboBox dialog
--menu <text> Menu dialog
--checklist <text> Check List dialog
--radiolist <text> Radio List dialog
--passivepopup <text> <timeout> Passive Popup
--icon <icon> Passive popup icon
--getopenfilename File dialog to open an existing file
(arguments [startDir] [filter])
--getsavefilename File dialog to save a file (arguments
[startDir] [filter])
--getexistingdirectory File dialog to select an existing directory
(arguments [startDir])
--getopenurl File dialog to open an existing URL
(arguments [startDir] [filter])
--getsaveurl File dialog to save a URL (arguments
[startDir] [filter])
--geticon Icon chooser dialog (arguments [group]
[context])
--progressbar <text> Progress bar dialog, returns a D-Bus
reference for communication
--getcolor Color dialog to select a color
--format <text> Allow --getcolor to specify output format
--title <text> Dialog title
--default <text> Default entry to use for combobox, menu and
color
--multiple Allows the --getopenurl and
--getopenfilename options to return multiple
files
--separate-output Return list items on separate lines (for
checklist option and file open with
--multiple)
--print-winid Outputs the winId of each dialog
--dontagain <file:entry> Config file and option name for saving the
"do-not-show/ask-again" state
--slider <text> Slider dialog box, returns selected value
--calendar <text> Calendar dialog box, returns selected date
--attach <winid> Makes the dialog transient for an X app
specified by winid
--embed <winid> A synonym for --attach
--geometry <geometry> Dialog geometry:
=]<width>{xX}<height>]{+-}<xoffset>{+-}<y
offset>]
Arguments:
[arg] Arguments - depending on main option
Cheers!
If “root” above refers to local user root - no, this command line does not make user’s graphical session available to root. See “man xhost”.
You are correct, I copied a command from my bash history without trying it out first. This xhost command is superfluous anyway.
It suffices for root to copy the .Xauthority file and then set the DISPLAY variable.
Thanks for the correction, arvidjaar. Cheers!
As I noted earlier,
using xhost is playing with fire… future changes may reveal more vulnerabilities and invalidate a use.
Recommend simply sending an xmessage with display variable, should be simple, uncomplicated and not likely to be invalidated in the future…
TSU
I noticed this old thread and thought I’d reply in case anyone else is looking for a way to notify desktop users via notify-send/dbus, the normal desktop notification system.
I have a bash script available as a github gist: https://gist.github.com/digitaltrails/26aad3282d8739db1de8bc2e59c812eb
The script allows root to notify local X11 and Wayland users by issuing notify-sends as each user. It uses loginctl to obtain session info, sudo and notify-send to issue messages. Some examples:
notify-desktop -a Daily-backup -t 0 -i dialog-information.png "Backup completed without error"
notify-desktop -a Remote-rsync -t 6000 -i dialog-warning.png "Remote host not currently on the network"
notify-desktop -a Daily-backup -t 0 -i dialog-error.png "Error running backup, please consult journalctl"
notify-desktop -a OS-Upgrade -t 0 -i dialog-warning.png "Update in progress, do not shutdown until further notice"
For X11 the script works straight out of the box.
Due to Wayland’s tighter security it can only work for Wayland if each user starts an xdg-dbus-proxy
for access to dbus. Each Wayland user would have to run the following on desktop login:
notify-desktop --create-dbus-proxy
(BTW, sudo isn’t strictly necessary, but I didn’t like running notify-send as root.)